From ietf-ipr@ietf.org Tue Dec 4 14:56:50 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED3D21F8706; Tue, 4 Dec 2012 14:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaNNNmbKvxrj; Tue, 4 Dec 2012 14:56:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6243221F870A; Tue, 4 Dec 2012 14:56:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: suresh.krishnan@ericsson.com, mirja.kuehlewind@ikr.uni-stuttgart.de, ralli@tid.es X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204225649.5793.8101.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 14:56:49 -0800 Cc: conex@ietf.org, ipr-announce@ietf.org Subject: [conex] IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:56:50 -0000 Dear Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo: An IPR disclosure that pertains to your Internet-Draft entitled "IPv6 Destination Option for ConEx" (draft-ietf-conex-destopt) was submitted to t= he IETF Secretariat on 2012-11-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Dec 4 14:56:50 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1821F870A; Tue, 4 Dec 2012 14:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcUx+H2wQbui; Tue, 4 Dec 2012 14:56:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B29E21F8ACA; Tue, 4 Dec 2012 14:56:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: mirja.kuehlewind@ikr.uni-stuttgart.de, rs@netapp.com X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204225649.5793.58590.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 14:56:49 -0800 Cc: conex@ietf.org, ipr-announce@ietf.org Subject: [conex] IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:56:50 -0000 Dear Mirja Kuehlewind, Richard Scheffenegger: An IPR disclosure that pertains to your Internet-Draft entitled "TCP modifications for Congestion Exposure" (draft-ietf-conex-tcp-modifications)= was submitted to the IETF Secretariat on 2012-11-22 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Dec 4 14:56:51 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7491121F8BD7; Tue, 4 Dec 2012 14:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn580sOQ+Z9r; Tue, 4 Dec 2012 14:56:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AEA21F8BC9; Tue, 4 Dec 2012 14:56:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: mattmathis@google.com, bob.briscoe@bt.com X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 14:56:49 -0800 Cc: conex@ietf.org, ipr-announce@ietf.org Subject: [conex] IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:56:51 -0000 Dear Matt Mathis, Bob J. Briscoe: An IPR disclosure that pertains to your Internet-Draft entitled "Congestion Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-abstrac= t- mech) was submitted to the IETF Secretariat on 2012-11-22 and has been post= ed on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From mattmathis@google.com Tue Dec 4 15:35:31 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D321F8BA3 for ; Tue, 4 Dec 2012 15:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-8vPaPfMrFn for ; Tue, 4 Dec 2012 15:35:30 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAD121F8BB2 for ; Tue, 4 Dec 2012 15:35:30 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1168034wib.13 for ; Tue, 04 Dec 2012 15:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UsU785wyYtj7DCktnk+wW5z/tGNjTS6ozQfgXIVstNk=; b=JHzBd1VAsvkxhGX0Mid9WHeHZIz6o89KNwW6ZgX6MoMGyWfzfDD6H9t9zIUf0bgYv5 xKH3nBm+JS9p3/PKTZZFWMd+ZaF5xMTgA5S3BQByNvefvlcjd1FNpjf9bFFLVbAuJl2e cFG1TIK5OUmLKeCoDWhD5GWUYPD7AUxIhlyzmjYOBZmsXkQQCCXTqxRnnQd/oy5GnXmw GZeSAItS3Ql04B1X5Swp0i0A47tlsB6j2qqvEPuu75cck/ERSjH36HirwxLkZXDJe/8D 4E0WMNGjRII0ibXDbIbZNZf6rgaIz77jeyKS3fBRMaW4AwJXxpirpPODiqQ49iKUYliv FAGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=UsU785wyYtj7DCktnk+wW5z/tGNjTS6ozQfgXIVstNk=; b=aDLgrvQOa39VyPsam09hImb3dq7IXsYiKw9rGca6z6E4KU9utdvriu0PbDEY5l1Ca1 9v0MNte286MxUbGXxvNWuW/XFQMM360xfkFoUUg7JLjDxsbAhzlcOKAJkcIXu7MsddIk 5G7FwUBUK5KQLGFd+9vIQqSNATiJChGGZkW03nJuRoIioE81Vuchgoz5nTAmTpZ6XTDO 1qXn36KiwqtGxuRmgIUpy4/wcrVwKo+NK1lD0Pf2wXdNzY06SWWHRCz9OBfUjT5khg33 mhaXnEYQen762oBbfiwGvU1hhGoLcYsdmeutjet0rJgYJQvLG978cR4yf+QA40i4DWj/ +IKg== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr42315wib.20.1354664128935; Tue, 04 Dec 2012 15:35:28 -0800 (PST) Received: by 10.227.61.20 with HTTP; Tue, 4 Dec 2012 15:35:28 -0800 (PST) In-Reply-To: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> References: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> Date: Tue, 4 Dec 2012 15:35:28 -0800 Message-ID: From: Matt Mathis To: bob.briscoe@bt.com Content-Type: multipart/alternative; boundary=f46d043c807031f5e504d00f5223 X-Gm-Message-State: ALoCoQkXoqQrLq8hN8dbT7qVVV90/D2vEwP1XNe+X1QsOYRz1BW5TFMps/mkh4vfpoa+foDm0OIyd0pimGNdsFnonxx6mpjq+icwop94IJSWlVLgDX02Zo9esv63WpsdWxevF10iZusfvqeS+Vkw/NDUr46K2PWJGzG7brJAtrgMAOnmhjFS6mnE95kkZygZclpdaFnsvVyu Cc: conex@ietf.org Subject: Re: [conex] IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 23:35:31 -0000 --f46d043c807031f5e504d00f5223 Content-Type: text/plain; charset=ISO-8859-1 (-IETF wide and secretariat lists) Bob, without a licencing statement, this IPR disclosure essentially kills ConEx..... Why should anybody in the IETF contribute free consulting to a technology which BT claims to own, and can at any time in the future charge what ever it pleases? Why should anybody in any of the OS communities do the same? Random Cisco statements say something like: The reasonable non-discriminatory terms are: If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. I hope such language is on its way. When was the patent application first submitted? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Dec 4, 2012 at 2:56 PM, IETF Secretariat wrote: > > Dear Matt Mathis, Bob J. Briscoe: > > An IPR disclosure that pertains to your Internet-Draft entitled "Congestion > Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-abstract- > mech) was submitted to the IETF Secretariat on 2012-11-22 and has been posted on > the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is > "British Telecommunications plc's statement about IPR claimed in draft-ietf- > conex-abstract-mech-04.txt.""); > > The IETF Secretariat > --f46d043c807031f5e504d00f5223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(= -IETF wide and secretariat lists)

Bob, without a licencing statement= , this IPR disclosure essentially kills ConEx..... =A0 Why should anybody i= n the IETF contribute free consulting to a technology which BT claims to ow= n, and can at any time in the future charge what ever it pleases? =A0Why sh= ould anybody in any of the OS communities do the same?

Random Cisco statements say something like:

The reasonable non-discriminato= ry terms are:

If this standard is adopted, Cisco will not assert any= patents owned or controlled by Cisco against
any party for making, using, selling, importing or offering for sale a pro= duct that implements the
standard, provided, however that Cisco retains= the right to assert its patents (including the right
to claim past roy= alties) against any party that asserts a patent it owns or controls (either=
directly or indirectly) against Cisco or any of Cisco's affiliates or = successors in title or against
any products of Cisco or any products of= any of Cisco's affiliates either alone or in combination
with othe= r products; and Cisco retains the right to assert its patents against any p= roduct or
portion thereof that is not necessary for compliance with the standard.

I hope such language is on its way.

Wh= en was the patent application first submitted?

Thanks,
--MM--
The best way to predict the future is to create it. = =A0- Alan Kay

Privacy matters! =A0We know from recent events that pe= ople are using our services to speak in defiance of unjust governments. =A0= We treat privacy and security as matters of life and death, because for so= me users, they are.


On Tue, Dec 4, 2012 at 2:56 PM, IETF Secretariat <ietf-ipr@ietf.org> wrote:
>
> Dea= r Matt Mathis, Bob J. Briscoe:
>
> =A0An IPR disclosure that pe= rtains to your Internet-Draft entitled "Congestion
> Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-con= ex-abstract-
> mech) was submitted to the IETF Secretariat on 2012-11= -22 and has been posted on
> the "IETF Page of Intellectual Prop= erty Rights Disclosures"
> (https://datatracke= r.ietf.org/ipr/1922/). The title of the IPR disclosure is
> "= ;British Telecommunications plc's statement about IPR claimed in draft-= ietf-
> conex-abstract-mech-04.txt."");
>
> The IETF Sec= retariat
>
--f46d043c807031f5e504d00f5223-- From marcelo@it.uc3m.es Tue Dec 4 22:36:30 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3A21F86B9 for ; Tue, 4 Dec 2012 22:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDYmilZJyRK4 for ; Tue, 4 Dec 2012 22:36:29 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7327A21F86B5 for ; Tue, 4 Dec 2012 22:36:29 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (dummyhost13.it.uc3m.es [163.117.139.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 423B1C358AD for ; Wed, 5 Dec 2012 07:36:24 +0100 (CET) Message-ID: <50BEEB67.3090009@it.uc3m.es> Date: Wed, 05 Dec 2012 07:36:23 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20121204225649.5793.8101.idtracker@ietfa.amsl.com> In-Reply-To: <20121204225649.5793.8101.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121204225649.5793.8101.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 05 Dec 2012 07:36:24 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19420.002 X-TM-AS-Result: No--5.861-7.0-31-1 X-imss-scan-details: No--5.861-7.0-31-1 Subject: [conex] Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 06:36:30 -0000 FYI -------- Mensaje original -------- Asunto: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt Fecha: Tue, 04 Dec 2012 14:56:49 -0800 De: IETF Secretariat Para: suresh.krishnan@ericsson.com, mirja.kuehlewind@ikr.uni-stuttgart.de, ralli@tid.es CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org Dear Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo: An IPR disclosure that pertains to your Internet-Draft entitled "IPv6 Destination Option for ConEx" (draft-ietf-conex-destopt) was submitted to the IETF Secretariat on 2012-11-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From marcelo@it.uc3m.es Tue Dec 4 22:40:59 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D17421F8C6A for ; Tue, 4 Dec 2012 22:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtkQh6NsQmbo for ; Tue, 4 Dec 2012 22:40:59 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3121F86CC for ; Tue, 4 Dec 2012 22:40:58 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (dummyhost13.it.uc3m.es [163.117.139.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 45651766CFE for ; Wed, 5 Dec 2012 07:40:53 +0100 (CET) Message-ID: <50BEEC75.8010301@it.uc3m.es> Date: Wed, 05 Dec 2012 07:40:53 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20121204225649.5793.58590.idtracker@ietfa.amsl.com> In-Reply-To: <20121204225649.5793.58590.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121204225649.5793.58590.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Wed, 05 Dec 2012 07:40:53 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19420.002 X-TM-AS-Result: No--6.278-7.0-31-1 X-imss-scan-details: No--6.278-7.0-31-1 Subject: [conex] Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 06:40:59 -0000 FYI (this is a different one) -------- Mensaje original -------- Asunto: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt Fecha: Tue, 04 Dec 2012 14:56:49 -0800 De: IETF Secretariat Para: mirja.kuehlewind@ikr.uni-stuttgart.de, rs@netapp.com CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org Dear Mirja Kuehlewind, Richard Scheffenegger: An IPR disclosure that pertains to your Internet-Draft entitled "TCP modifications for Congestion Exposure" (draft-ietf-conex-tcp-modifications) was submitted to the IETF Secretariat on 2012-11-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From marcelo@it.uc3m.es Tue Dec 4 22:41:17 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796C21F859A for ; Tue, 4 Dec 2012 22:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inOGXqN5ub6e for ; Tue, 4 Dec 2012 22:41:16 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 823A621F84F8 for ; Tue, 4 Dec 2012 22:41:16 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (dummyhost13.it.uc3m.es [163.117.139.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 6DC2AC36261 for ; Wed, 5 Dec 2012 07:41:15 +0100 (CET) Message-ID: <50BEEC8B.8030309@it.uc3m.es> Date: Wed, 05 Dec 2012 07:41:15 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20121204225649.5793.59586.idtracker@ietfa.amsl.com> In-Reply-To: <20121204225649.5793.59586.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121204225649.5793.59586.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 05 Dec 2012 07:41:15 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19420.002 X-TM-AS-Result: No--4.946-7.0-31-1 X-imss-scan-details: No--4.946-7.0-31-1 Subject: [conex] Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 06:41:17 -0000 yet another one -------- Mensaje original -------- Asunto: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt Fecha: Tue, 04 Dec 2012 14:56:49 -0800 De: IETF Secretariat Para: kutscher@neclab.eu, faisal.mir@neclab.eu, winter@neclab.eu, suresh.krishnan@ericsson.com, ying.zhang@ericsson.com, cjbc@it.uc3m.es CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org Dear Dirk Kutscher, Faisal Mir, Rolf Winter, Suresh Krishnan, Ying Zhang, Carlos Jésus Bernardos: An IPR disclosure that pertains to your Internet-Draft entitled "Mobile Communication Congestion Exposure Scenario" (draft-ietf-conex-mobile) was submitted to the IETF Secretariat on 2012-11-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From marcelo@it.uc3m.es Tue Dec 4 22:41:34 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC021F859A for ; Tue, 4 Dec 2012 22:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E3nIiQk-tWr for ; Tue, 4 Dec 2012 22:41:34 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70C21F84F8 for ; Tue, 4 Dec 2012 22:41:34 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (dummyhost13.it.uc3m.es [163.117.139.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 7DC12CB7CFE for ; Wed, 5 Dec 2012 07:41:32 +0100 (CET) Message-ID: <50BEEC9C.50604@it.uc3m.es> Date: Wed, 05 Dec 2012 07:41:32 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> In-Reply-To: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Wed, 05 Dec 2012 07:41:32 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19420.002 X-TM-AS-Result: No--2.956-7.0-31-1 X-imss-scan-details: No--2.956-7.0-31-1 Subject: [conex] Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 06:41:34 -0000 and the last one (for now at least) -------- Mensaje original -------- Asunto: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt Fecha: Tue, 04 Dec 2012 14:56:49 -0800 De: IETF Secretariat Para: mattmathis@google.com, bob.briscoe@bt.com CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org Dear Matt Mathis, Bob J. Briscoe: An IPR disclosure that pertains to your Internet-Draft entitled "Congestion Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-abstract- mech) was submitted to the IETF Secretariat on 2012-11-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is "British Telecommunications plc's statement about IPR claimed in draft-ietf- conex-abstract-mech-04.txt.""); The IETF Secretariat From bob.briscoe@bt.com Wed Dec 5 02:02:47 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6074621F893E for ; Wed, 5 Dec 2012 02:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpSrkE8gNpHi for ; Wed, 5 Dec 2012 02:02:46 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 534F321F8938 for ; Wed, 5 Dec 2012 02:02:46 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 10:02:41 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 10:02:44 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.318.4; Wed, 5 Dec 2012 10:02:40 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qB5A2dIC023248; Wed, 5 Dec 2012 10:02:39 GMT Message-ID: <201212051002.qB5A2dIC023248@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 5 Dec 2012 10:02:38 +0000 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <50BEEC9C.50604@it.uc3m.es> References: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> <50BEEC9C.50604@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: 'ConEx IETF list' Subject: Re: [conex] Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:02:47 -0000 Marcelo and the ConEx list (including authors of affected drafts), All these emails relate to the same screwed up IPR disclosure, which was actually meant to be good news. This disclosure has been screwed up - our IPR dept sent text to the IETF IPR people by email, who must have then transcribed it wrongly into the form - omitting the actual licensing text sent by BT's lawyer. It was intended to offer a royalty-free license under terms unchanged from the original IPR declaration for re-ECN , which this declaration was meant to update solely by adding more drafts and more patents. I have asked for the omitted license text to be added urgently. I have been asking for an update to this declaration since March 2011 (!!!). It has been frustrating for me, because I couldn't say in advance what terms would be applied in the updated declaration, because the lawyers (rightly) require that only they can state BT's licensing terms. It has taken this long because the IETF IPR process first required each draft to be declared individually, then when the IETF admitted that all the drafts could be on one form, the form couldn't handle the number of drafts, so the tools team had to modify the form software. Although I never expected it to take this long, I kept everyone informed about this: * to the ConEx list and in my presentations during the ConEx BoFs (2010) * to the ConEx chairs and concepts-uses authors in response to a question from Nandita when concepts uses went to the IESG (26 Mar 2012) Bob At 06:41 05/12/2012, marcelo bagnulo braun wrote: >and the last one (for now at least) > > >-------- Mensaje original -------- >Asunto: IPR Disclosure: British Telecommunications plc's >statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt >Fecha: Tue, 04 Dec 2012 14:56:49 -0800 >De: IETF Secretariat >Para: mattmathis@google.com, bob.briscoe@bt.com >CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, >marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org > > > >Dear Matt Mathis, Bob J. Briscoe: > > An IPR disclosure that pertains to your Internet-Draft entitled "Congestion >Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-abstract- >mech) was submitted to the IETF Secretariat on 2012-11-22 and has >been posted on >the "IETF Page of Intellectual Property Rights Disclosures" >(https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is >"British Telecommunications plc's statement about IPR claimed in draft-ietf- >conex-abstract-mech-04.txt.""); > >The IETF Secretariat > > > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Dec 5 02:11:21 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B67B21F87CA for ; Wed, 5 Dec 2012 02:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8kDOATb5P+q for ; Wed, 5 Dec 2012 02:11:15 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71121F8973 for ; Wed, 5 Dec 2012 02:11:15 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 10:11:14 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 10:11:10 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.318.4; Wed, 5 Dec 2012 10:11:05 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qB5AB4qK023295; Wed, 5 Dec 2012 10:11:04 GMT Message-ID: <201212051011.qB5AB4qK023295@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 5 Dec 2012 10:11:04 +0000 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <20121204225649.5793.60567.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_50111336==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: conex@ietf.org Subject: Re: [conex] IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:11:21 -0000 --=====================_50111336==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Matt, See my email to the ConEx list. This was an administrative screw up - omitting the actual license text. Bob At 23:35 04/12/2012, Matt Mathis wrote: >(-IETF wide and secretariat lists) > >Bob, without a licencing statement, this IPR disclosure essentially >kills ConEx..... Why should anybody in the IETF contribute free >consulting to a technology which BT claims to own, and can at any >time in the future charge what ever it pleases? Why should anybody >in any of the OS communities do the same? > >Random Cisco statements say something like: > >The reasonable non-discriminatory terms are: > >If this standard is adopted, Cisco will not assert any patents owned >or controlled by Cisco against >any party for making, using, selling, importing or offering for sale >a product that implements the >standard, provided, however that Cisco retains the right to assert >its patents (including the right >to claim past royalties) against any party that asserts a patent it >owns or controls (either >directly or indirectly) against Cisco or any of Cisco's affiliates >or successors in title or against >any products of Cisco or any products of any of Cisco's affiliates >either alone or in combination >with other products; and Cisco retains the right to assert its >patents against any product or >portion thereof that is not necessary for compliance with the standard. > > >I hope such language is on its way. > >When was the patent application first submitted? > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > >Privacy matters! We know from recent events that people are using >our services to speak in defiance of unjust governments. We treat >privacy and security as matters of life and death, because for some >users, they are. > > >On Tue, Dec 4, 2012 at 2:56 PM, IETF Secretariat ><ietf-ipr@ietf.org> wrote: > > > > Dear Matt Mathis, Bob J. Briscoe: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Congestion > > Exposure (ConEx) Concepts and Abstract Mechanism" > (draft-ietf-conex-abstract- > > mech) was submitted to the IETF Secretariat on 2012-11-22 and has > been posted on > > the "IETF Page of Intellectual Property Rights Disclosures" > > > (https://datatracker.ietf.org/ipr/1922/). > The title of the IPR disclosure is > > "British Telecommunications plc's statement about IPR claimed in > draft-ietf- > > conex-abstract-mech-04.txt.""); > > > > The IETF Secretariat > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_50111336==.ALT Content-Type: text/html; charset="us-ascii" Matt,

See my email to the ConEx list.
This was an administrative screw up - omitting the actual license text.

Bob

At 23:35 04/12/2012, Matt Mathis wrote:
(-IETF wide and secretariat lists)

Bob, without a licencing statement, this IPR disclosure essentially kills ConEx.....   Why should anybody in the IETF contribute free consulting to a technology which BT claims to own, and can at any time in the future charge what ever it pleases?  Why should anybody in any of the OS communities do the same?

Random Cisco statements say something like:

The reasonable non-discriminatory terms are:

If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against
any party for making, using, selling, importing or offering for sale a product that implements the
standard, provided, however that Cisco retains the right to assert its patents (including the right
to claim past royalties) against any party that asserts a patent it owns or controls (either
directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against
any products of Cisco or any products of any of Cisco's affiliates either alone or in combination
with other products; and Cisco retains the right to assert its patents against any product or
portion thereof that is not necessary for compliance with the standard.


I hope such language is on its way.

When was the patent application first submitted?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.


On Tue, Dec 4, 2012 at 2:56 PM, IETF Secretariat <ietf-ipr@ietf.org> wrote:
>
> Dear Matt Mathis, Bob J. Briscoe:
>
>  An IPR disclosure that pertains to your Internet-Draft entitled "Congestion
> Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-abstract-
> mech) was submitted to the IETF Secretariat on 2012-11-22 and has been posted on
> the "IETF Page of Intellectual Property Rights Disclosures"
> ( https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is
> "British Telecommunications plc's statement about IPR claimed in draft-ietf-
> conex-abstract-mech-04.txt."");
>
> The IETF Secretariat
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_50111336==.ALT-- From bob.briscoe@bt.com Wed Dec 5 11:42:14 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B293E21F8615 for ; Wed, 5 Dec 2012 11:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6zXBLNNTc60 for ; Wed, 5 Dec 2012 11:42:12 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3524A21F85DA for ; Wed, 5 Dec 2012 11:42:12 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 19:42:05 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 19:42:10 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.318.4; Wed, 5 Dec 2012 19:42:09 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.16.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qB5Jg8Rf025440; Wed, 5 Dec 2012 19:42:08 GMT Message-ID: <201212051942.qB5Jg8Rf025440@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 5 Dec 2012 19:42:06 +0000 To: Marcelo BAGNULO BRAUN , Nandita Dukkipati , "Eddy Wesley M. [VZ]" From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: [conex] Fwd: Re: Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:42:14 -0000 Marcelo, Nandita, Wes, ConEx list, The IETF IPR administrator has now added the mistakenly omitted license terms to the end of the declaration, that is still at the same URL: Bob >Date: Wed, 05 Dec 2012 10:02:38 +0000 >To: marcelo bagnulo braun >From: Bob Briscoe >Subject: Re: [conex] Fwd: IPR Disclosure: British Telecommunications >plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt >Cc: "'ConEx IETF list'" > >Marcelo and the ConEx list (including authors of affected drafts), > >All these emails relate to the same screwed up IPR disclosure, which >was actually meant to be good news. > >This disclosure has been screwed up - our IPR dept sent text to the >IETF IPR people by email, who must have then transcribed it wrongly >into the form - omitting the actual licensing text sent by BT's lawyer. > >It was intended to offer a royalty-free license under terms >unchanged from the original IPR declaration for re-ECN >, which this declaration was >meant to update solely by adding more drafts and more patents. > >I have asked for the omitted license text to be added urgently. > >I have been asking for an update to this declaration since March >2011 (!!!). It has been frustrating for me, because I couldn't say >in advance what terms would be applied in the updated declaration, >because the lawyers (rightly) require that only they can state BT's >licensing terms. > >It has taken this long because the IETF IPR process first required >each draft to be declared individually, then when the IETF admitted >that all the drafts could be on one form, the form couldn't handle >the number of drafts, so the tools team had to modify the form software. > >Although I never expected it to take this long, I kept everyone >informed about this: >* to the ConEx list and in my presentations during the ConEx BoFs (2010) >* to the ConEx chairs and concepts-uses authors in response to a >question from Nandita when concepts uses went to the IESG (26 Mar 2012) > > >Bob > >At 06:41 05/12/2012, marcelo bagnulo braun wrote: >>and the last one (for now at least) >> >> >>-------- Mensaje original -------- >>Asunto: IPR Disclosure: British Telecommunications plc's >>statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt >>Fecha: Tue, 04 Dec 2012 14:56:49 -0800 >>De: IETF Secretariat >>Para: mattmathis@google.com, bob.briscoe@bt.com >>CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, >>marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org >> >> >> >>Dear Matt Mathis, Bob J. Briscoe: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Congestion >>Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-abstract- >>mech) was submitted to the IETF Secretariat on 2012-11-22 and has >>been posted on >>the "IETF Page of Intellectual Property Rights Disclosures" >>(https://datatracker.ietf.org/ipr/1922/). The title of the IPR disclosure is >>"British Telecommunications plc's statement about IPR claimed in draft-ietf- >>conex-abstract-mech-04.txt.""); >> >>The IETF Secretariat >> >> >> >> >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From mattmathis@google.com Wed Dec 5 11:50:07 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BAE21F8CBD for ; Wed, 5 Dec 2012 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRx8EIclniFs for ; Wed, 5 Dec 2012 11:49:56 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1A21F8CBE for ; Wed, 5 Dec 2012 11:49:55 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so2402094wgb.13 for ; Wed, 05 Dec 2012 11:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bq6yFaMADFlsYmj4owI0Fz4z2nvY0s+XBRSsvBU3NPA=; b=Nw03++z+P5VQUpJXxVj2qmE52uPQT5hoyun8lVz0e0wo6ab/x0AULaD4gAwyTCwhb8 GPv5OViRFmrlU8UxblnFfV0RVznRCEv9G/6xojZEUbrgBVKa++qmRd5R5YWGy8WUIjir L5vEMt5ifYOobsrXi7666C1L2lKAaJzBbX/LmErwXn1rbCxhLnxVl93Wjnlpd27MjAPn 3wAfTdl9tCiNNwBBuPJvO0Pc3K3uZWAZZQqFbpY6KmlvhhGxxnGJzkFK+AKRCnQwnMLQ 4HrIsLB9IbwsqSE32+bjNlafWzdMCaO68ncFhEZ4zQ0V/4UvBoRrdfZby6CfzBxzYnGy ZA0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Bq6yFaMADFlsYmj4owI0Fz4z2nvY0s+XBRSsvBU3NPA=; b=TmFRHrAS6eabO+JSFgVwRVR51VH9bQMCdc+uXS9+33/kExzcy2i74qQ/sK/OGzMUa+ m49tTNges/wTx/jU1JIFK5xXuUtjr8DsIYmv7b8tNKAAwllAQI9cNZZ+HIGoSsxM+N59 t7LzVODMkaQXDt/FYANXEN2/yn/yegU+gojJNqDIEHh2NZGQY+2xPczNyhr+vdnzOySp vIxpZaG1BN+vYbnel+dV3ZPcxOjenlEBtsKt2SXIGfhyrKFQCJIKaq51SO3RCTkYd5kH p6uaf6jFntkAENtsdfmQ82CUHFrPfoLVWCBxalMRiwy/nyCD71SXi8wLClEhC5clehys qa2A== MIME-Version: 1.0 Received: by 10.216.28.213 with SMTP id g63mr6674105wea.66.1354736994566; Wed, 05 Dec 2012 11:49:54 -0800 (PST) Received: by 10.227.61.20 with HTTP; Wed, 5 Dec 2012 11:49:54 -0800 (PST) In-Reply-To: <201212051942.qB5Jg8Rf025440@bagheera.jungle.bt.co.uk> References: <201212051942.qB5Jg8Rf025440@bagheera.jungle.bt.co.uk> Date: Wed, 5 Dec 2012 11:49:54 -0800 Message-ID: From: Matt Mathis To: Bob Briscoe Content-Type: multipart/alternative; boundary=0016e6db680553416b04d020496e X-Gm-Message-State: ALoCoQkhy/zARRtnjsthk54/6BT375YwoT9VpoV1/FWh/oBUB41IEMl1bzPs4hxZNyt/yNALLMapCZOj8oEzgEtPUhOBRiar8YZpmaqPwjBDE2jbapqjynYCf1IxsCb4dDF9FpX3DlWZLcpw+CTACo/TzIS88ExYlSn1QrOLi6W0c3gqtak9WhSEBZ52OJ+QrEAOdaB4HmJU Cc: ConEx IETF list , "Eddy Wesley M. \[VZ\]" Subject: Re: [conex] Fwd: Re: Fwd: IPR Disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:50:07 -0000 --0016e6db680553416b04d020496e Content-Type: text/plain; charset=ISO-8859-1 Thank you! --MM-- The best way to predict the future is to create it. - Alan Kay On Wed, Dec 5, 2012 at 11:42 AM, Bob Briscoe wrote: > Marcelo, Nandita, Wes, ConEx list, > > The IETF IPR administrator has now added the mistakenly omitted license > terms to the end of the declaration, that is still at the same URL: > > > > > > > Bob > > Date: Wed, 05 Dec 2012 10:02:38 +0000 >> To: marcelo bagnulo braun >> From: Bob Briscoe >> Subject: Re: [conex] Fwd: IPR Disclosure: British Telecommunications >> plc's statement about IPR claimed in draft-ietf-conex-abstract-** >> mech-04.txt >> Cc: "'ConEx IETF list'" >> >> >> Marcelo and the ConEx list (including authors of affected drafts), >> >> All these emails relate to the same screwed up IPR disclosure, which was >> actually meant to be good news. >> >> This disclosure has been screwed up - our IPR dept sent text to the IETF >> IPR people by email, who must have then transcribed it wrongly into the >> form - omitting the actual licensing text sent by BT's lawyer. >> >> It was intended to offer a royalty-free license under terms unchanged >> from the original IPR declaration for re-ECN < >> https://datatracker.ietf.org/**ipr/651/>, >> which this declaration was meant to update solely by adding more drafts and >> more patents. >> >> I have asked for the omitted license text to be added urgently. >> >> I have been asking for an update to this declaration since March 2011 >> (!!!). It has been frustrating for me, because I couldn't say in advance >> what terms would be applied in the updated declaration, because the lawyers >> (rightly) require that only they can state BT's licensing terms. >> >> It has taken this long because the IETF IPR process first required each >> draft to be declared individually, then when the IETF admitted that all the >> drafts could be on one form, the form couldn't handle the number of drafts, >> so the tools team had to modify the form software. >> >> Although I never expected it to take this long, I kept everyone informed >> about this: >> * to the ConEx list and in my presentations during the ConEx BoFs (2010) >> * to the ConEx chairs and concepts-uses authors in response to a question >> from Nandita when concepts uses went to the IESG (26 Mar 2012) >> >> >> Bob >> >> At 06:41 05/12/2012, marcelo bagnulo braun wrote: >> >>> and the last one (for now at least) >>> >>> >>> -------- Mensaje original -------- >>> Asunto: IPR Disclosure: British Telecommunications plc's >>> statement about IPR claimed in draft-ietf-conex-abstract-**mech-04.txt >>> Fecha: Tue, 04 Dec 2012 14:56:49 -0800 >>> De: IETF Secretariat >>> Para: mattmathis@google.com, bob.briscoe@bt.com >>> CC: wes@mti-systems.com, martin.stiemerling@neclab.eu, >>> marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, >>> ipr-announce@ietf.org >>> >>> >>> >>> Dear Matt Mathis, Bob J. Briscoe: >>> >>> An IPR disclosure that pertains to your Internet-Draft entitled >>> "Congestion >>> Exposure (ConEx) Concepts and Abstract Mechanism" >>> (draft-ietf-conex-abstract- >>> mech) was submitted to the IETF Secretariat on 2012-11-22 and has been >>> posted on >>> the "IETF Page of Intellectual Property Rights Disclosures" >>> (https://datatracker.ietf.org/**ipr/1922/). >>> The title of the IPR disclosure is >>> >>> "British Telecommunications plc's statement about IPR claimed in >>> draft-ietf- >>> conex-abstract-mech-04.txt."")**; >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/**listinfo/conex >>> >> >> ______________________________**______________________________**____ >> Bob Briscoe, BT Innovate & Design >> > > ______________________________**______________________________**____ > Bob Briscoe, BT Innovate & Design > ______________________________**_________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/**listinfo/conex > --0016e6db680553416b04d020496e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

T= hank you!
--MM--
The best way to predict the future is = to create it. =A0- Alan Kay

On Wed, Dec 5= , 2012 at 11:42 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:=
Marcelo, Nandita, Wes, ConEx list,

The IETF IPR administrator has now added the mistakenly omitted license ter= ms to the end of the declaration, that is still at the same URL:
<ht= tps://datatracker.ietf.org/ipr/1922/>



Bob

Date: Wed, 05 Dec 2012 10:02:38 +0000
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: [conex] Fwd: IPR Disclosure: British Telecommunications plc= 9;s statement about IPR claimed in draft-ietf-conex-abstract-mech-04= .txt
Cc: "'ConEx IETF list'" <conex@ietf.org>


Marcelo and the ConEx list (including authors of affected drafts),

All these emails relate to the same screwed up IPR disclosure, which was ac= tually meant to be good news.

This disclosure has been screwed up - our IPR dept sent text to the IETF IP= R people by email, who must have then transcribed it wrongly into the form = - omitting the actual licensing text sent by BT's lawyer.

It was intended to offer a royalty-free license under terms unchanged from = the original IPR declaration for re-ECN <https://datatracker.ietf.org/ip= r/651/>, which this declaration was meant to update solely by adding= more drafts and more patents.

I have asked for the omitted license text to be added urgently.

I have been asking for an update to this declaration since March 2011 (!!!)= . It has been frustrating for me, because I couldn't say in advance wha= t terms would be applied in the updated declaration, because the lawyers (r= ightly) require that only they can state BT's licensing terms.

It has taken this long because the IETF IPR process first required each dra= ft to be declared individually, then when the IETF admitted that all the dr= afts could be on one form, the form couldn't handle the number of draft= s, so the tools team had to modify the form software.

Although I never expected it to take this long, I kept everyone informed ab= out this:
* to the ConEx list and in my presentations during the ConEx BoFs (2010) * to the ConEx chairs and concepts-uses authors in response to a question f= rom Nandita when concepts uses went to the IESG (26 Mar 2012)


Bob

At 06:41 05/12/2012, marcelo bagnulo braun wrote:
and the last one (for now at least)


-------- Mensaje original --------
Asunto: =A0 =A0 =A0 =A0 IPR Disclosure: British Telecommunications plc'= s statement about IPR claimed in draft-ietf-conex-abstract-mech-04.t= xt
Fecha: =A0Tue, 04 Dec 2012 14:56:49 -0800
De: =A0 =A0 IETF Secretariat <ietf-ipr@ietf.org>
Para: =A0 mattma= this@google.com, bob.briscoe@bt.com
CC: =A0 =A0 wes@mt= i-systems.com, martin.stiemerling@neclab.eu, marcelo@it.uc3m.es, nanditad@google.com, conex@ietf.org, ipr-announce@ietf.org



Dear Matt Mathis, Bob J. Briscoe:

=A0An IPR disclosure that pertains to your Internet-Draft entitled "Co= ngestion
Exposure (ConEx) Concepts and Abstract Mechanism" (draft-ietf-conex-ab= stract-
mech) was submitted to the IETF Secretariat on 2012-11-22 and has been post= ed on
the "IETF Page of Intellectual Property Rights Disclosures"
(https= ://datatracker.ietf.org/ipr/1922/). The title of the IPR disclos= ure is

"British Telecommunications plc's statement about IPR claimed in d= raft-ietf-
conex-abstract-mech-04.txt."");

The IETF Secretariat





_______________________________________________
conex mailing list
conex@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/conex

_____________________________________________________________= ___
Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0BT Innovate & Design

_____________________________________________________________= ___
Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0BT Innovate & Design
_______________________________________________
conex mailing list
conex@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/conex

--0016e6db680553416b04d020496e-- From wwwrun@rfc-editor.org Wed Dec 5 17:28:57 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E921F89CB; Wed, 5 Dec 2012 17:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89PhU24MkA-6; Wed, 5 Dec 2012 17:28:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8821F8997; Wed, 5 Dec 2012 17:28:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id ED0CE72F4EF; Wed, 5 Dec 2012 17:20:39 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121206012039.ED0CE72F4EF@rfc-editor.org> Date: Wed, 5 Dec 2012 17:20:39 -0800 (PST) Cc: conex@ietf.org, rfc-editor@rfc-editor.org Subject: [conex] RFC 6789 on Congestion Exposure (ConEx) Concepts and Use Cases X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:28:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6789 Title: Congestion Exposure (ConEx) Concepts and Use Cases Author: B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed. Status: Informational Stream: IETF Date: December 2012 Mailbox: bob.briscoe@bt.com, richard_woundy@cable.comcast.com, acooper@cdt.org Pages: 17 Characters: 41078 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-conex-concepts-uses-05.txt URL: http://www.rfc-editor.org/rfc/rfc6789.txt This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Congestion Exposure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From marcelo@it.uc3m.es Thu Dec 6 07:27:11 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86521F8546 for ; Thu, 6 Dec 2012 07:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBjHaTtsaL9y for ; Thu, 6 Dec 2012 07:27:10 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5301821F8545 for ; Thu, 6 Dec 2012 07:27:10 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 8D7909D7137 for ; Thu, 6 Dec 2012 16:27:07 +0100 (CET) Message-ID: <50C0B949.3020007@it.uc3m.es> Date: Thu, 06 Dec 2012 16:27:05 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20121206012039.ED0CE72F4EF@rfc-editor.org> In-Reply-To: <20121206012039.ED0CE72F4EF@rfc-editor.org> X-Forwarded-Message-Id: <20121206012039.ED0CE72F4EF@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Thu, 06 Dec 2012 16:27:08 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19426.000 X-TM-AS-Result: No--22.464-7.0-31-1 X-imss-scan-details: No--22.464-7.0-31-1 Subject: [conex] Fwd: RFC 6789 on Congestion Exposure (ConEx) Concepts and Use Cases X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:27:11 -0000 We have our first document out. Thanks to the WG and specially the editors for their work. -------- Mensaje original -------- Asunto: [conex] RFC 6789 on Congestion Exposure (ConEx) Concepts and Use Cases Fecha: Wed, 5 Dec 2012 17:20:39 -0800 (PST) De: rfc-editor@rfc-editor.org Para: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: conex@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6789 Title: Congestion Exposure (ConEx) Concepts and Use Cases Author: B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed. Status: Informational Stream: IETF Date: December 2012 Mailbox: bob.briscoe@bt.com, richard_woundy@cable.comcast.com, acooper@cdt.org Pages: 17 Characters: 41078 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-conex-concepts-uses-05.txt URL: http://www.rfc-editor.org/rfc/rfc6789.txt This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Congestion Exposure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Mon Dec 10 10:25:57 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0285321F85A5 for ; Mon, 10 Dec 2012 10:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.2 X-Spam-Level: X-Spam-Status: No, score=-105.2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uPo7WwQ1Cr3 for ; Mon, 10 Dec 2012 10:25:56 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id AAE2621F8567 for ; Mon, 10 Dec 2012 10:25:55 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (3.38.218.87.dynamic.jazztel.es [87.218.38.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 271B771594A for ; Mon, 10 Dec 2012 19:25:54 +0100 (CET) Message-ID: <50C62931.7040408@it.uc3m.es> Date: Mon, 10 Dec 2012 19:25:53 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: 'ConEx IETF list' References: <20121210181121.8172.32105.idtracker@ietfa.amsl.com> In-Reply-To: <20121210181121.8172.32105.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121210181121.8172.32105.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTHACL 134 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Mon, 10 Dec 2012 19:25:54 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-19438.001 X-TM-AS-Result: No--40.684-7.0-31-1 X-imss-scan-details: No--40.684-7.0-31-1 Subject: [conex] Fwd: 86th IETF - Working Group/BOF/IRTF Scheduling X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:25:57 -0000 Hi, I wonder if we have to meet in orlando. Opinions? Regards, marcelo -------- Mensaje original -------- Asunto: 86th IETF - Working Group/BOF/IRTF Scheduling Fecha: Mon, 10 Dec 2012 10:11:21 -0800 De: IETF Agenda Para: Working Group Chairs CC: irsg@irtf.org ----------------------------------------------------------------- 86th IETF – Orlando, FL, USA Meeting Dates: March 10-15, 2013 Host: Comcast and NBC Universal ----------------------------------------------------------------- IETF meetings start Monday morning and run through Friday afternoon (13:30). We are accepting scheduling requests for all Working Groups, BOFs, and IRTFs starting today. The milestones and deadlines for scheduling-related activities are as follows: NOTE: cutoff dates are subject to change. - 2012-12-10 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. - 2013-01-14 (Monday): Cutoff date for requests to schedule Working Group meetings at UTC 24:00. To request a Working Group session, use the IETF Meeting Session Request Tool. - 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area Directors at UTC 24:00. To request a BOF, please see instructions on Requesting a BOF. - 2013-01-31 (Thursday): Cutoff date for Area Directors to approve BOFs at UTC 24:00. - 2013-02-07 (Thursday): Preliminary agenda published for comment. - 2013-02-11 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings UTC 24:00. - 2013-02-15 (Friday): Final agenda to be published. - 2013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. - 2013-03-04 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. - 2013-04-12 (Friday): Proceedings submission cutoff date by UTC 24:00, upload using IETF Meeting Materials Management Tool. - 2013-05-01 (Wednesday): Proceedings submission corrections cutoff date by UTC 24:00, upload using IETF Meeting Materials Management Tool. Submitting Requests for Working Group and BOF Sessions Please submit requests to schedule your Working Group sessions using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information that the Secretariat requires to schedule your sessions. The URL for the tool is: https://pub.ietf.org/sreq/ Please send requests to schedule your BOF sessions to agenda@ietf.org. Please include the acronym of your BOF in the subject line of the message, and include all of the information specified in item (4) of "Requesting Meeting Sessions at IETF Meetings" in the body. (This document is included below.) Submitting Session Agendas For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible. Draft Working Group agendas are due Wednesday, February 27, 2013 at UTC 24:00. Revised Working Group agendas are due no later than Monday, March 4, 2013 at UTC 24:00. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved. The URL for the tool is: https://pub.ietf.org/proceedings/ Additional information about this tool is available at: http://www.ietf.org/instructions/meeting_materials_tool.html Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" Web page as soon as they are submitted. The URL for the "IETF 86 Meeting Materials" Web page is: https://datatracker.ietf.org/meeting/86/materials.html If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to: ietf-action@ietf.org. =============================================================== For your convenience, comprehensive information on requesting meeting sessions at IETF 86 is presented below: 1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is: https://pub.ietf.org/sreq/ Instructions for using the tool are available at: http://www.ietf.org/instructions/session_request_tool_instruction.html If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s). Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s). When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line. 2. BOFs will NOT be scheduled unless the Area Director(s) approved the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs. 3. A Working Group may request either one or two sessions. If your Working Group requires more than two sessions, then your request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Monday, February 11, 2013, the cut-off date for requests to reschedule a session. 4. You MUST provide the following information before a Working Group or BOF session will be scheduled: a. Working Group or BOF full name with acronym in brackets: b. AREA under which Working Group or BOF appears: c. CONFLICTS you wish to avoid, please be as specific as possible: d. Expected Attendance: e. Special requests: f. Number of sessions: g. Length of session: - 1 hour - 1 1/2 hours - 2 hours - 2 1/2 hours For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt). =============================================================== For your convenience please find here a list of the IETF Area Directors with their e-mail addresses: IETF Chair Russ Housley Applications Area (app) Barry Leiba Pete Resnick Internet Area (int) Ralph Droms Brian Haberman Operations & Management Area (ops) Ronald Bonica Benoit Claise Real-time Applications and Infrastructure Area (rai) Gonzalo Camarillo Robert Sparks Routing Area (rtg) Stewart Bryant Adrian Farrel Security Area (sec) Stephen Farrell Sean Turner Transport Area (tsv) Wesley Eddy Martin Stiemerling =========================================================== 85th IETF Meeting Attendance Number 6man - 153 6renum - 30 abfab 47 alto - 59 apparea (AG) - 122 atoca - 20 avtcore (2nd session) - 60 avtext - 40 bmwg - 34 ccamp (2nd session) - 52 cdni - 54 cdni (2nd session) - 51 certrans - 99 clue - 55 clue (2nd session) - 53 core - 64 core (2nd session) - 50 dhc - 62 dime - 23 dispatch - 53 dtnrg (RG) - 39 ecrit - 36 eman - 44 emu - 25 forces - 44 geopriv - 41 httpauth - 103 httpbis - 85 iccrg (RG) - 81 idr - 62 intarea (AG) - 105 ippm - 56 iri - 26 irs - 291 IRTF Open Meeting - 82 isis - 34 karp - 46 l3vpn - 63 mdnsext - 164 mif - 68 mile - 39 mpls (2nd session) - 79 mptcp - 63 multimob - 21 netext - 46 netmod - 41 nvo3 (BoF) - 198 oauth - 65 opsawg - 66 opsec - 45 pce - 74 pcp - 27 pim - 24 pkix - 30 ppsp - 28 radext - 18 rmcat (BoF) - 64 rtcweb (2nd session) - 145 rtgarea (AG) - 72 rtgwg - 113 sacm - 63 sdnrg (RG) - 264 sidr - 65 siprec - 29 softwire - 89 softwire (2nd session) - 79 sunset4 - 142 tcpm - 32 tictoc - 23 tls - 80 trill - 38 tsvarea (AG) - 92 tsvwg - 38 tsvwg (2nd session) - 48 v6ops - 146 videocodec - 142 wpkops - 100 From bob.briscoe@bt.com Mon Dec 10 13:53:04 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1E721F853B for ; Mon, 10 Dec 2012 13:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAD_CREDIT=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRAKNqhTUrXU for ; Mon, 10 Dec 2012 13:53:02 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 50B4C21F8514 for ; Mon, 10 Dec 2012 13:52:59 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Dec 2012 21:52:56 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Dec 2012 21:52:56 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.318.4; Mon, 10 Dec 2012 21:52:56 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.24.25]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qBALqs50022813; Mon, 10 Dec 2012 21:52:54 GMT Message-ID: <201212102152.qBALqs50022813@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Dec 2012 21:52:12 +0000 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson .se> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Ingemar Johansson S , "conex@ietf.org" Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:53:05 -0000 Ingemar, You're right. Good point. Certainly true for downstream cases out of the cellular network, where long-running flows are not uncommon. When I wrote that, I wasn't thinking of mobility, I was thinking of much less frequent re-routing after failures, so I wasn't trying to make it seamless. For explicit hand-overs as in the case you describe, there's explicit hand-over of operational state, so it wouldn't be impossible to hand-over credit too. Am I right, at least in an arm-wavy sense? We should make it clear that the only state that re-creates itself is the flow-ID state, not the credit associated with it. I wrote that sentence (not Matt), and my motivation was to explain that a switch to a different audit wouldn't be catastrophic for the flow. I wasn't trying to claim that it would hand-over without a glitch. The audit would drop some packets, so the flow would send some Re-Echo-Loss, which would establish some credit and the flow could continue. Bob Sorry for delay replying. At 13:27 21/11/2012, Ingemar Johansson S wrote: >Hi > >First time I had time to read carefully through this document >The document is comprehensible and I don't find any serious issues with it. > >One comment though on page 5, 3rd para. >" the flow-state required for audit creates itself as it detects new >flows. Therefore a flow will not fail if it is re- > routed away from the audit box currently holding its flow-state. " > >If I map ConEx to a 3GPP LTE use case, the audit functions are best >placed in the eNodeB. When a new (long lived) flow is created it is >preferably preloaded with credit marks which are stored in the >auditor in the eNodeB which the terminal is "connected" to. When the >terminal hands over to another eNodeB the credit marks will be >lost. This means that the ConEx markings will in this case be at >least one RTT behind with a higher risk of false positives in the >auditor in the new eNodeB >To avoid this the credit marks would need to be forwarded to the new >eNodeB via e.g the X2 interface. > >So my question is, is it needed to add a statement that mentions this ? > >/Ingemar > >-----Original Message----- >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >Behalf Of marcelo bagnulo braun >Sent: 23 October 2012 06:54 >To: 'ConEx IETF list' >Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt > >Hi, > >This note issues the WGLC for > >draft-ietf-conex-abstract-mech-06.txt > >Please reivew the document and provide comments. The WGLC will close >on the 20th of november. > >For you convenience, the draft can be found at: > >https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech > >Regards, marcelo > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Dec 10 14:33:00 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D3121F8654 for ; Mon, 10 Dec 2012 14:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeQukrSh4q0B for ; Mon, 10 Dec 2012 14:32:59 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id B59E521F863C for ; Mon, 10 Dec 2012 14:32:58 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Dec 2012 22:32:55 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 10 Dec 2012 22:32:54 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.318.4; Mon, 10 Dec 2012 22:32:54 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.24.25]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qBAMWq6N022982; Mon, 10 Dec 2012 22:32:52 GMT Message-ID: <201212102232.qBAMWq6N022982@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Dec 2012 22:32:51 +0000 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <50C62931.7040408@it.uc3m.es> References: <20121210181121.8172.32105.idtracker@ietfa.amsl.com> <50C62931.7040408@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: 'ConEx IETF list' Subject: Re: [conex] Fwd: 86th IETF - Working Group/BOF/IRTF Scheduling X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:33:00 -0000 Marcelo, Five things I'd like to hear by then (two are my own): 1/ Now that concept-uses is out as RFC6789, I=20 will focus on abstract-mech. I will resolve to=20 pick up the discussions that I've been missing.=20 I'd like to have that off to the IESG before=20 March. But if we get bogged down, we will need to sort this out in Orlando. 2&3/ I can't speak for the other immediate=20 milestones (destopt, tcp-modifications), but they=20 should be able to follow fairly quickly after abstract-mech. 4/ I admit I've been fairly much buried in=20 internal BT fluff for some months. I should have=20 time for some more practical work from now on. I have been promised a Linux implementation of=20 ConEx shortly, and I'm currently getting the=20 go-ahead to deploy it into BT's data centre=20 testbed to evaluate the design in=20 draft-briscoe-conex-data-centre. Should be able to report on that by March. 5/ I'd like to hear a presentation from Zhu Lei &=20 co-authors, who have an interesting draft:=20 draft-zhang-tsvwg-tunnel-congestion-exposure-00.=20 It doesn't need ConEx, instead it uses feedback=20 across a tunnel to get congestion information to=20 the ingress. A network operator can unilaterally=20 deploy this neat idea to capture 80% (?) of the benefits of ConEx. And the network can turn on ECN unilaterally so=20 the tunnel egress can detect congestion easily=20 without burying into transport headers to look=20 for gaps in sequence numbers. Then for e2e=20 traffic that isn't ECN-capable, the tunnel egress=20 will naturally turn ECN marks into drops just by complying with [RFC6040]. I suggested (offlist) they should require that=20 the tunnel doesn't do congestion feedback for=20 ConEx-enabled packets. Then, as ConEx is=20 deployed, the tunnel just fills in congestion=20 feedback for non-ConEx traffic. So more ConEx=20 makes it more efficient (and it adds the benefit=20 of credit marking, which makes a big difference=20 for lots of short flows). There's some open=20 questions, but it's interesting.=20 Conex-data-centre uses a tunnel in a similar way. Bob At 18:25 10/12/2012, marcelo bagnulo braun wrote: >Hi, > >I wonder if we have to meet in orlando. >Opinions? > >Regards, marcelo > > > >-------- Mensaje original -------- >Asunto: 86th IETF - Working Group/BOF/IRTF Scheduling >Fecha: Mon, 10 Dec 2012 10:11:21 -0800 >De: IETF Agenda >Para: Working Group Chairs >CC: irsg@irtf.org > > > >----------------------------------------------------------------- >86th IETF =AD Orlando, FL, USA >Meeting Dates: March 10-15, 2013 >Host: Comcast and NBC Universal >----------------------------------------------------------------- >IETF meetings start Monday morning and run through Friday afternoon= (13:30). > >We are accepting scheduling requests for all=20 >Working Groups, BOFs, and IRTFs starting=20 >today. The milestones and deadlines for=20 >scheduling-related activities are as follows: > >NOTE: cutoff dates are subject to change. > >- 2012-12-10 (Monday): Working Group and BOF=20 >scheduling begins. To request a Working Group=20 >session, use the IETF Meeting Session Request Tool. >- 2013-01-14 (Monday): Cutoff date for requests=20 >to schedule Working Group meetings at UTC 24:00.=20 >To request a Working Group session, use the IETF Meeting Session Request= Tool. >- 2013-01-28 (Monday): Cutoff date for BOF=20 >proposal requests to Area Directors at UTC=20 >24:00. To request a BOF, please see instructions on Requesting a BOF. >- 2013-01-31 (Thursday): Cutoff date for Area=20 >Directors to approve BOFs at UTC 24:00. >- 2013-02-07 (Thursday): Preliminary agenda published for comment. >- 2013-02-11 (Monday): Cutoff date for requests=20 >to reschedule Working Group and BOF meetings UTC 24:00. >- 2013-02-15 (Friday): Final agenda to be published. >- 2013-02-27 (Wednesday): Draft Working Group=20 >agendas due by UTC 24:00, upload using IETF Meeting Materials Management= Tool. >- 2013-03-04 (Monday): Revised Working Group=20 >agendas due by UTC 24:00, upload using IETF Meeting Materials Management= Tool. >- 2013-04-12 (Friday): Proceedings submission=20 >cutoff date by UTC 24:00, upload using IETF Meeting Materials Management= Tool. >- 2013-05-01 (Wednesday): Proceedings submission=20 >corrections cutoff date by UTC 24:00, upload=20 >using IETF Meeting Materials Management Tool. > >Submitting Requests for Working Group and BOF Sessions > >Please submit requests to schedule your Working=20 >Group sessions using the "IETF Meeting Session=20 >Request Tool," a Web-based tool for submitting=20 >all of the information that the Secretariat requires to schedule your= sessions. > >The URL for the tool is: > >https://pub.ietf.org/sreq/ > >Please send requests to schedule your BOF=20 >sessions to agenda@ietf.org. Please include the=20 >acronym of your BOF in the subject line of the=20 >message, and include all of the information=20 >specified in item (4) of "Requesting Meeting=20 >Sessions at IETF Meetings" in the body. (This document is included below.) > >Submitting Session Agendas > >For the convenience of meeting attendees, we ask=20 >that you submit the agendas for your Working=20 >Group sessions as early as possible. Draft=20 >Working Group agendas are due Wednesday,=20 >February 27, 2013 at UTC 24:00. Revised Working=20 >Group agendas are due no later than Monday,=20 >March 4, 2013 at UTC 24:00. The proposed agenda=20 >for a BOF session should be submitted along with=20 >your request for a session. Please be sure to=20 >copy your Area Director on that message. > >Please submit the agendas for your Working Group=20 >sessions using the "IETF Meeting Materials=20 >Management Tool," a Web-based tool for making=20 >your meeting agenda, minutes, and presentation=20 >slides available to the community before,=20 >during, and after an IETF meeting. If you are a=20 >BOF chair, then you may use the tool to submit a=20 >revised agenda as well as other materials for=20 >your BOF once the BOF has been approved. > >The URL for the tool is: > >https://pub.ietf.org/proceedings/ > >Additional information about this tool is available at: > >http://www.ietf.org/instructions/meeting_materials_tool.html > >Agendas submitted via the tool will be available=20 >to the public on the "IETF Meeting Materials"=20 >Web page as soon as they are submitted. > >The URL for the "IETF 86 Meeting Materials" Web page is: > >https://datatracker.ietf.org/meeting/86/materials.html > >If you are a Working Group chair, then you=20 >already have accounts on the "IETF Meeting=20 >Session Request Tool" and the "IETF Meeting=20 >Materials Management Tool." The same User ID=20 >and password will work for both tools. If you=20 >are a BOF chair who is not also a Working Group=20 >chair, then you will be given an account on the=20 >"IETF Meeting Materials Management Tool" when=20 >your BOF has been approved. If you require=20 >assistance in using either tool, or wish to=20 >report a bug, then please send a message to: >ietf-action@ietf.org. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >For your convenience, comprehensive information=20 >on requesting meeting sessions at IETF 86 is presented below: > >1. Requests to schedule Working Group sessions=20 >should be submitted using the "IETF Meeting=20 >Session Request Tool," a Web-based tool for=20 >submitting all of the information required by=20 >the Secretariat to schedule your sessions. The URL for the tool is: > >https://pub.ietf.org/sreq/ > >Instructions for using the tool are available at: > >http://www.ietf.org/instructions/session_request_tool_instruction.html > >If you require an account on this tool, or=20 >assistance in using it, then please send a=20 >message to ietf-action@ietf.org. If you are=20 >unable to use the tool, then you may send your=20 >request via e-mail to agenda@ietf.org, with a=20 >copy to the appropriate Area Director(s). > >Requests to schedule BOF sessions must be sent=20 >to agenda@ietf.org with a copy to the appropriate Area Director(s). > >When submitting a Working Group or BOF session=20 >request by e-mail, please include the Working=20 >Group or BOF acronym in the Subject line. > >2. BOFs will NOT be scheduled unless the Area=20 >Director(s) approved the BOF. The proponents=20 >behind a BOF need to contact a relevant Area=20 >Director, preferably well in advance of the BOF=20 >approval deadline date. The AD needs to have the=20 >full name of the BOF, its acronym, suggested=20 >names of chairs, an agenda, full description of=20 >the BOF and the information covered in item 4.=20 >Please read RFC 5434 for instructions on how to=20 >drive a successful BOF effort. The approval=20 >depends on, for instance, Internet-Drafts and=20 >list discussion on the suggested topic. BOF=20 >agenda requests, if approved, will be submitted=20 >to the IETF Secretariat by the ADs. > >3. A Working Group may request either one or two=20 >sessions. If your Working Group requires more=20 >than two sessions, then your request must be=20 >approved by an Area Director. Additional=20 >sessions will be assigned, based on=20 >availability, after Monday, February 11, 2013,=20 >the cut-off date for requests to reschedule a session. > >4. You MUST provide the following information=20 >before a Working Group or BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance: > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > >For more information on scheduling Working Group=20 >and BOF sessions, please refer to RFC 2418 (BCP=20 >25), "IETF Working Group Guidelines and=20 >Procedures" (http://www.ietf.org/rfc/rfc2418.txt). >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >For your convenience please find here a list of=20 >the IETF Area Directors with their e-mail addresses: > >IETF Chair >Russ Housley > >Applications Area (app) >Barry Leiba >Pete Resnick > >Internet Area (int) >Ralph Droms >Brian Haberman > >Operations & Management Area (ops) >Ronald Bonica >Benoit Claise > >Real-time Applications and Infrastructure Area (rai) >Gonzalo Camarillo >Robert Sparks > >Routing Area (rtg) >Stewart Bryant >Adrian Farrel > >Security Area (sec) >Stephen Farrell >Sean Turner > >Transport Area (tsv) >Wesley Eddy >Martin Stiemerling > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >85th IETF Meeting Attendance Number > >6man - 153 >6renum - 30 >abfab 47 >alto - 59 >apparea (AG) - 122 >atoca - 20 >avtcore (2nd session) - 60 >avtext - 40 >bmwg - 34 >ccamp (2nd session) - 52 >cdni - 54 >cdni (2nd session) - 51 >certrans - 99 >clue - 55 >clue (2nd session) - 53 >core - 64 >core (2nd session) - 50 >dhc - 62 >dime - 23 >dispatch - 53 >dtnrg (RG) - 39 >ecrit - 36 >eman - 44 >emu - 25 >forces - 44 >geopriv - 41 >httpauth - 103 >httpbis - 85 >iccrg (RG) - 81 >idr - 62 >intarea (AG) - 105 >ippm - 56 >iri - 26 >irs - 291 >IRTF Open Meeting - 82 >isis - 34 >karp - 46 >l3vpn - 63 >mdnsext - 164 >mif - 68 >mile - 39 >mpls (2nd session) - 79 >mptcp - 63 >multimob - 21 >netext - 46 >netmod - 41 >nvo3 (BoF) - 198 >oauth - 65 >opsawg - 66 >opsec - 45 >pce - 74 >pcp - 27 >pim - 24 >pkix - 30 >ppsp - 28 >radext - 18 >rmcat (BoF) - 64 >rtcweb (2nd session) - 145 >rtgarea (AG) - 72 >rtgwg - 113 >sacm - 63 >sdnrg (RG) - 264 >sidr - 65 >siprec - 29 >softwire - 89 >softwire (2nd session) - 79 >sunset4 - 142 >tcpm - 32 >tictoc - 23 >tls - 80 >trill - 38 >tsvarea (AG) - 92 >tsvwg - 38 >tsvwg (2nd session) - 48 >v6ops - 146 >videocodec - 142 >wpkops - 100 > > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From ingemar.s.johansson@ericsson.com Thu Dec 13 01:46:55 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F321F893D for ; Thu, 13 Dec 2012 01:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAD_CREDIT=0.001, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi2IXuXzyTj1 for ; Thu, 13 Dec 2012 01:46:54 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B658A21F8934 for ; Thu, 13 Dec 2012 01:46:53 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-50-50c9a40c1844 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 71.17.04318.C04A9C05; Thu, 13 Dec 2012 10:46:52 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.136]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 10:46:52 +0100 From: Ingemar Johansson S To: Bob Briscoe Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt Thread-Index: AQHNx1njVg+tGahsb06Ne07rnDfUVZf0Q9ZwgB5u8XSAA+pQQA== Date: Thu, 13 Dec 2012 09:46:51 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA059F14@ESESSMB205.ericsson.se> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> <201212102152.qBALqs50022813@bagheera.jungle.bt.co.uk> In-Reply-To: <201212102152.qBALqs50022813@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjS7PkpMBBusn61lMX/+F0eLQtZ+M DkwebV8mM3ksWfKTKYApissmJTUnsyy1SN8ugStj8qL17AWbFSr+bn/N1sD4ULKLkZNDQsBE 4sXJVawQtpjEhXvr2UBsIYFDjBJNv4q6GLmA7CWMEjOefGQHSbAJ2EisPPSdEcQWEVCROLZz BjOIzSygKrHv0SwWEFtYwFli+8kzrBA1LhJTb/6Dsp0kupb/ZOpi5OBgAarvng12A6+At8SL HQtZIPYeY5JYdVUXxOYEGrP14R2wVYwCshL3v99jgVglLnHryXwmiJsFJJbsOc8MYYtKvHz8 D+oXRYmPr/YxQtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FSN7bmJmTnq5+SZGYIQc3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamAUXzOjSU3e/f1P0elFIjc1047/383kMMFm0Qu2Bbc/TPatYo35lGQZcrk23+bT 2hUqn4zXvpx+KulQzZfOHGWltctcoz/ETJjBz+WivVL/8pKvQtPN7x556uXxWd2+0tj03tmW R+qbwnac2z+7XPtBk4ScwNV7azaaHIo65SdVmGuX3hlq4nxMiaU4I9FQi7moOBEA6vHMg14C AAA= Cc: "conex@ietf.org" Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:46:55 -0000 Hi Comments inline /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: den 10 december 2012 22:52 > To: Ingemar Johansson S > Cc: conex@ietf.org; Ingemar Johansson S > Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt >=20 > Ingemar, >=20 > You're right. Good point. Certainly true for downstream cases out of the > cellular network, where long-running flows are not uncommon. [IJ] Also, novel features like HTTP 2.0 and SPDY may make persistent TCP co= nnections more common. >=20 > When I wrote that, I wasn't thinking of mobility, I was thinking of much = less > frequent re-routing after failures, so I wasn't trying to make it seamles= s. >=20 > For explicit hand-overs as in the case you describe, there's explicit han= d-over > of operational state, so it wouldn't be impossible to hand-over credit to= o. Am > I right, at least in an arm-wavy sense? [IJ] Yes, one option is to transfer the credit via the X2 interface, needs = standardization of course (not in IETF though) >=20 > We should make it clear that the only state that re-creates itself is the= flow- > ID state, not the credit associated with it. I wrote that sentence (not M= att), > and my motivation was to explain that a switch to a different audit would= n't > be catastrophic for the flow. I wasn't trying to claim that it would hand= -over > without a glitch. The audit would drop some packets, so the flow would se= nd > some Re-Echo-Loss, which would establish some credit and the flow could > continue. [IJ] Hmm, perhaps I did not get that part, what you say is that if the audi= t drops a packet, that will count as a credit ?. This credit thing is is s= till a mystery so I probably need to get this explained better... >=20 >=20 > Bob >=20 > Sorry for delay replying. >=20 > At 13:27 21/11/2012, Ingemar Johansson S wrote: > >Hi > > > >First time I had time to read carefully through this document The > >document is comprehensible and I don't find any serious issues with it. > > > >One comment though on page 5, 3rd para. > >" the flow-state required for audit creates itself as it detects new > >flows. Therefore a flow will not fail if it is re- > > routed away from the audit box currently holding its flow-state. " > > > >If I map ConEx to a 3GPP LTE use case, the audit functions are best > >placed in the eNodeB. When a new (long lived) flow is created it is > >preferably preloaded with credit marks which are stored in the auditor > >in the eNodeB which the terminal is "connected" to. When the terminal > >hands over to another eNodeB the credit marks will be lost. This means > >that the ConEx markings will in this case be at least one RTT behind > >with a higher risk of false positives in the auditor in the new eNodeB > >To avoid this the credit marks would need to be forwarded to the new > >eNodeB via e.g the X2 interface. > > > >So my question is, is it needed to add a statement that mentions this ? > > > >/Ingemar > > > >-----Original Message----- > >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > >Of marcelo bagnulo braun > >Sent: 23 October 2012 06:54 > >To: 'ConEx IETF list' > >Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt > > > >Hi, > > > >This note issues the WGLC for > > > >draft-ietf-conex-abstract-mech-06.txt > > > >Please reivew the document and provide comments. The WGLC will close > on > >the 20th of november. > > > >For you convenience, the draft can be found at: > > > >https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech > > > >Regards, marcelo > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Dec 13 05:25:05 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE78821F879F for ; Thu, 13 Dec 2012 05:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAD_CREDIT=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0QuQKyVBA0w for ; Thu, 13 Dec 2012 05:25:04 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 773A021F8436 for ; Thu, 13 Dec 2012 05:25:04 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Dec 2012 13:25:03 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Dec 2012 13:25:02 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.318.4; Thu, 13 Dec 2012 13:24:58 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.33.117]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qBDDOurW004789; Thu, 13 Dec 2012 13:24:57 GMT Message-ID: <201212131324.qBDDOurW004789@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Dec 2012 13:24:57 +0000 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA059F14@ESESSMB205.ericsson .se> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> <201212102152.qBALqs50022813@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA059F14@ESESSMB205.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "conex@ietf.org" Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:25:05 -0000 Ingemar, At 09:46 13/12/2012, Ingemar Johansson S wrote: > > We should make it clear that the only state that re-creates > itself is the flow- > > ID state, not the credit associated with it. I wrote that > sentence (not Matt), > > and my motivation was to explain that a switch to a different > audit wouldn't > > be catastrophic for the flow. I wasn't trying to claim that it > would hand-over > > without a glitch. The audit would drop some packets, so the flow would send > > some Re-Echo-Loss, which would establish some credit and the flow could > > continue. >[IJ] Hmm, perhaps I did not get that part, what you say is that if >the audit drops a packet, that will count as a credit ?. This >credit thing is is still a mystery so I probably need to get this >explained better... OK, I think I promised Marcelo I would write a draft about audit, with a couple of example algorithms. I suspect that would help clear up many of these questions. For now, example stateful and stateless audit pseudocode and evaluations are here: (Section 7.6) Here's an overview: Very brief (for those who mostly get it already): ---------- The audit function doesn't count its own losses when balancing Re-Echo-Loss against Loss, because they are /audit/ losses, not congestion losses. So, if a flow is re-routed to a new audit function that doesn't hold any state about this flow, it will start discarding a low level of packets (audit discard). This will trigger the sender to Re-Echo-Loss in the next round trip, which will make the flow's audit balance positive and stop further audit discards. So, the flow has naturally created new state at the new audit function without the flow explicitly knowing that the burst of loss was due to a re-route into a new audit function which caused the flow's credit state at the original audit function to be lost. Brief but fuller explanation: ---------------------------- Re-Echo is always at least a round trip behind (longer for e.g. RTCP). The audit function makes the sender responsible for making the allowance for its feedback delay, by having to mark sufficient credit packets. Then the audit function can just test instantaneous negativity, without having to allow for RTT or feedback delays that it doesn't know. I'll assume a stateful audit function (stateless is possible, but it has to be less precise). For the duration of a flow, a stateful audit function counts bytes of different ConEx markings, and it will start dropping packets if * the balance of (Credit + Re-Echo-ECN - ECN) goes negative, or * the balance of (Credit + Re-Echo-Loss - Loss) goes negative. {See note} Consider a re-route where a flow is switched to a different stateful audit function, and assume the audit functions don't hand-over their state. * As soon as the flow suffers any loss or ECN in the network, the flow will go negative at the new audit function for at least a RTT, because it has no credit and no Re-Echo for at least a round trip. * So audit starts dropping packets (a very small but growing proportion). * Importantly, the audit doesn't count these discards as loss because they are its own /audit/ losses not congestion losses. * The sender gets the loss feedback from the receiver and sends some Re-Echo-Loss markings to balance. * These make the flow positive at the new audit function, because it didn't count its own discards. So, the flow has naturally created new state at the new audit function without explicitly knowing that the burst of loss was due to a re-route. Cheers Bob {Note: Let's set aside the question of how an audit function knows how much loss an upstream node has done - abstract-mech talks about that separately.} ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Thu Dec 13 06:20:53 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2391721F8967 for ; Thu, 13 Dec 2012 06:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAD_CREDIT=0.001, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYqRoReeMX2n for ; Thu, 13 Dec 2012 06:20:50 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEA021F8AD5 for ; Thu, 13 Dec 2012 06:20:48 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-10-50c9e440c16c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 20.27.04318.044E9C05; Thu, 13 Dec 2012 15:20:48 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.136]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 15:20:47 +0100 From: Ingemar Johansson S To: Bob Briscoe Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt Thread-Index: AQHNx1njVg+tGahsb06Ne07rnDfUVZf0Q9ZwgB5u8XSAA+pQQIAAPsMugAAO0TA= Date: Thu, 13 Dec 2012 14:20:46 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA05A2E9@ESESSMB205.ericsson.se> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> <201212102152.qBALqs50022813@bagheera.jungle.bt.co.uk> <81564C0D7D4D2A4B9A86C8C7404A13DA059F14@ESESSMB205.ericsson.se> <201212131324.qBDDOurW004789@bagheera.jungle.bt.co.uk> In-Reply-To: <201212131324.qBDDOurW004789@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja7Dk5MBBgsPCFpMX/+F0eLQtZ+M DkwebV8mM3ksWfKTKYApissmJTUnsyy1SN8ugSvj846ggu3KFf2fdrM2MP6Q7mLk5JAQMJHY 0fmQCcIWk7hwbz1bFyMXh5DAIUaJHQdXMUE4Sxglrp1uZgSpYhOwkVh56DuYLSKgInFs5wxm EJtZQFVi36NZLCC2sICzxPaTZ1ghalwkpt78B2RzANl+EqeWhoOYLEDlrQdiQCp4Bbwl+rs7 oFYdZJZonTEJbAwn0JhFL5rBxjAKyErc/36PBWKVuMStJ/OhjhaQWLLnPDOELSrx8vE/Vghb UeLjq32MEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxcie m5iZk15uvokRGCEHt/w22MG46b7YIUZpDhYlcV491f3+QgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhg35hTyf9det/23tzdHTkFFsaLd1UsrPIyKmi5FvPuw0lz+OFtx87Sau5zc6SWr5hp4 3d17p/ut2B+vWVeWaXulf+dIn/Fx6kbeJenprWpbXM3zmmfu0jJicornLTl67fGNV1Pfvtkx kyOpccOJxkMH/yl5X9jTOLF4/sOU4/JKCnf/ya4xfZ+nxFKckWioxVxUnAgApeHvUl4CAAA= Cc: "conex@ietf.org" Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:20:53 -0000 Hi Thanks for the explanation now I get it! /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: den 13 december 2012 14:25 > To: Ingemar Johansson S > Cc: conex@ietf.org > Subject: RE: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt >=20 > Ingemar, >=20 > At 09:46 13/12/2012, Ingemar Johansson S wrote: > > > We should make it clear that the only state that re-creates > > itself is the flow- > > > ID state, not the credit associated with it. I wrote that > > sentence (not Matt), > > > and my motivation was to explain that a switch to a different > > audit wouldn't > > > be catastrophic for the flow. I wasn't trying to claim that it > > would hand-over > > > without a glitch. The audit would drop some packets, so the flow > > > would send some Re-Echo-Loss, which would establish some credit and > > > the flow could continue. > >[IJ] Hmm, perhaps I did not get that part, what you say is that if the > >audit drops a packet, that will count as a credit ?. This credit thing > >is is still a mystery so I probably need to get this explained > >better... >=20 > OK, I think I promised Marcelo I would write a draft about audit, with a > couple of example algorithms. I suspect that would help clear up many of > these questions. >=20 > For now, example stateful and stateless audit pseudocode and evaluations > are here: > (Section 7.6) >=20 > Here's an overview: >=20 > Very brief (for those who mostly get it already): > ---------- > The audit function doesn't count its own losses when balancing Re-Echo-Lo= ss > against Loss, because they are /audit/ losses, not congestion losses. >=20 > So, if a flow is re-routed to a new audit function that doesn't hold any = state > about this flow, it will start discarding a low level of packets (audit = discard). > This will trigger the sender to Re-Echo-Loss in the next round trip, whic= h will > make the flow's audit balance positive and stop further audit discards. >=20 > So, the flow has naturally created new state at the new audit function > without the flow explicitly knowing that the burst of loss was due to a r= e- > route into a new audit function which caused the flow's credit state at t= he > original audit function to be lost. >=20 >=20 > Brief but fuller explanation: > ---------------------------- > Re-Echo is always at least a round trip behind (longer for e.g. > RTCP). The audit function makes the sender responsible for making the > allowance for its feedback delay, by having to mark sufficient credit pac= kets. > Then the audit function can just test instantaneous negativity, without > having to allow for RTT or feedback delays that it doesn't know. >=20 > I'll assume a stateful audit function (stateless is possible, but it has = to be less > precise). For the duration of a flow, a stateful audit function counts by= tes of > different ConEx markings, and it will start dropping packets if > * the balance of (Credit + Re-Echo-ECN - ECN) goes negative, or > * the balance of (Credit + Re-Echo-Loss - Loss) goes negative. {See note} >=20 > Consider a re-route where a flow is switched to a different stateful audi= t > function, and assume the audit functions don't hand-over their state. >=20 > * As soon as the flow suffers any loss or ECN in the network, the flow wi= ll go > negative at the new audit function for at least a RTT, because it has no = credit > and no Re-Echo for at least a round trip. > * So audit starts dropping packets (a very small but growing proportion). > * Importantly, the audit doesn't count these discards as loss because the= y > are its own /audit/ losses not congestion losses. > * The sender gets the loss feedback from the receiver and sends some Re- > Echo-Loss markings to balance. > * These make the flow positive at the new audit function, because it didn= 't > count its own discards. >=20 > So, the flow has naturally created new state at the new audit function > without explicitly knowing that the burst of loss was due to a re-route. >=20 >=20 > Cheers >=20 >=20 > Bob >=20 > {Note: Let's set aside the question of how an audit function knows how > much loss an upstream node has done - abstract-mech talks about that > separately.} >=20 >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT Innovate & Design From mattmathis@google.com Wed Dec 19 08:08:32 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10721F853E for ; Wed, 19 Dec 2012 08:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I21eaYLx4gRR for ; Wed, 19 Dec 2012 08:08:32 -0800 (PST) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1131721F847B for ; Wed, 19 Dec 2012 08:08:31 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id x48so1028257wey.22 for ; Wed, 19 Dec 2012 08:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b9mI6JTLgPT/vqjzhivAWwv/rGwGyQS5ZhgGpWMdDXc=; b=dwNCuv4IxcFJyJ5CnzRZheYrDWagErTIiHjjx5RAml7Fn4aRmUHofPRkxF3IJyGe44 eDP+io21p5EYGN2kiUh/5kFMN8aXnJOpNStv8YQOvD9cuaqM5r8RodVPTHrqeB3tYQGe f6A/heWJaHZKc+W+TasQ6HJQPbTR1xKWBg6uYYUQgPlpg6qrl/eia0XAGuZk2eD6hEHY 7tGaEQJAEXDm+K2IIazCLtXQJuZ8S2VWixoPw+rK+d8zM23LDv8XLAf5uCtyAQGIBbFa vJobC1ERPN2aLB5eiqF3rgX5R6znXjpALjSN+9RWaPkmBkeEjMuateaq7CVgeS+p/cnO LN4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=b9mI6JTLgPT/vqjzhivAWwv/rGwGyQS5ZhgGpWMdDXc=; b=ZGPe3HJR4gaoHKkJDhpZ6knbxRUFh5Jf93U79gvjwYTBHqxWCf79fwRq5F72MheZIy ayNtH5Pgn9GikIN1llWtXXLKfIe4crQWEaobyqqLS2Nqbrt2Ogt1ktB5rrBmUS8oCal+ PbOKRFJjiHBUMlIBDCpXX5R/6hy1i3Yz/rQfEl37Q6kr59Qeg4JqZxqrieEOf6mURgnZ sbu+YelyVw4EBIu1PB1ljESHRacaIQGWa6iRByxYcLXgxaOujRU9xfXeQH221PgBHXN1 Q2esjsPHKjPraETwR61ecr56onwm6vExY2Wu6o+mlZQ0/xzcpj0V7BFVgXEhHdPu2nk4 hizQ== MIME-Version: 1.0 Received: by 10.180.99.129 with SMTP id eq1mr4942785wib.30.1355933311015; Wed, 19 Dec 2012 08:08:31 -0800 (PST) Received: by 10.227.196.2 with HTTP; Wed, 19 Dec 2012 08:08:30 -0800 (PST) Date: Wed, 19 Dec 2012 08:08:30 -0800 Message-ID: From: Matt Mathis To: ConEx IETF list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlPf9Eb46Nxc3oiOhuHE0oTEqbYsFvxgEPu5WZpqtPLVl2TVS5PSdAFdRcjofOV4koCwirGXPQSbhufMD6XDV9GKEeG4La+scbqKskcK7aSi6pNPx7Ez/IGrIQQt+sAl0DZjLt444n0+/Chtc6xrriewb1YiMiekRLX2VHOT3PXCrExjXMoTIzdmvjA3O+aw+Wpu7zg Subject: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:08:33 -0000 An interesting video, relevant to this group: "Jonas Eliasson: How to solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks] Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From swmike@swm.pp.se Wed Dec 19 09:03:42 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4E21F842D for ; Wed, 19 Dec 2012 09:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZdcoePK7U0f for ; Wed, 19 Dec 2012 09:03:41 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEE321F8421 for ; Wed, 19 Dec 2012 09:03:40 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1F8BC9C; Wed, 19 Dec 2012 18:03:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1BBBC9A; Wed, 19 Dec 2012 18:03:38 +0100 (CET) Date: Wed, 19 Dec 2012 18:03:38 +0100 (CET) From: Mikael Abrahamsson To: Matt Mathis In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ConEx IETF list Subject: Re: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:03:42 -0000 On Wed, 19 Dec 2012, Matt Mathis wrote: > An interesting video, relevant to this group: "Jonas Eliasson: How to > solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks] I have some input. The system he's talking about (Stockholm congestion charging system) costs around 100MUSD per year to operate. How much roads could we get for the same amount of money, and would that be a better investment? The answer seems to have been "no". (I live in Stockholm, I'm one of the people he's referring to who disliked the system initially and who now likes it). So let's take the analogy to this group. How much would it cost to bring in an infrastructure to create the incentives to make people adapt to move some of their traffic to another part of the day, or not run the traffic at all (which is what a traffic congestion system tries to achieve). I don't believe I have seen a system that actually reduces cost by trying to intelligently manage congestion or moving traffic spatially, compared to the cost of building out the network. A lot of the success of the Internet has been flat-rate billing so one basically doesn't have to have a lot of system and staff to handle usage-based billing. I don't really see how a congestion management system would fare any better. It adds complexity to the Network and I don't see how it would really help. Basically I don't see the incentives for the user to change. But I'd gladly be proven wrong, that's why I follow this mailing list. -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Wed Dec 19 09:20:09 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C0A21F87AE for ; Wed, 19 Dec 2012 09:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.257 X-Spam-Level: X-Spam-Status: No, score=-106.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je0IR3+y9mFx for ; Wed, 19 Dec 2012 09:20:09 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 48D0921F87A6 for ; Wed, 19 Dec 2012 09:20:09 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E203333C20; Wed, 19 Dec 2012 12:20:08 -0500 (EST) Date: Wed, 19 Dec 2012 12:20:08 -0500 From: John Leslie To: Matt Mathis Message-ID: <20121219172008.GM75059@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:20:10 -0000 Matt Mathis wrote: > > An interesting video, relevant to this group: "Jonas Eliasson: How to > solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks] Indeed! ~ 1-euro tolls at congestion points reduced traffic 20% and totally solved the congestion. But the amazing part is, nobody noticed they had changed anything; and most amazing of all, roughly half of those who initially opposed the tolls came to believe they had liked them all along! ;^) I've believed all along that ConEx can operate on a sender-pays model with "settlements" where essentially nobody will notice having changed anything and everybody will believe they've always been in favor... (Not that we are in any way charged to design a settlement system.) The point I _would_ like to make is that I believe "cheaters" will be found out naturally in any real-world "settlement" system without us needing to prescribe a particular method in the protocol. (It's probably good to _describe_ _a_ method; but entirely different methods are likely to be the ones actually used.) And... I recommend the video! -- John Leslie From swmike@swm.pp.se Wed Dec 19 09:28:09 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6046821F87A6 for ; Wed, 19 Dec 2012 09:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6R6VS10jeeE for ; Wed, 19 Dec 2012 09:28:09 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2D21F84DB for ; Wed, 19 Dec 2012 09:28:08 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 251B49E; Wed, 19 Dec 2012 18:28:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2096B9A for ; Wed, 19 Dec 2012 18:28:08 +0100 (CET) Date: Wed, 19 Dec 2012 18:28:08 +0100 (CET) From: Mikael Abrahamsson To: ConEx IETF list In-Reply-To: <20121219172008.GM75059@verdi> Message-ID: References: <20121219172008.GM75059@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:28:09 -0000 On Wed, 19 Dec 2012, John Leslie wrote: > ~ 1-euro tolls at congestion points reduced traffic 20% and totally > solved the congestion. 2 EUR per passing, and no, it didn't solve the congestion, it made it less (I guess it would have been a worse talk if he actually would have presented real figures). What he also doesn't talk about is that after that 20% decrease in traffic, traffic still increased yearly at the same rate so now we have multi-hour congestion again (basically they bought 5-8 years to implement a real solution, and then did nothing). But I'm digressing, I'm still interested in how this could be done on the Internet in a cost-effective way (both OPEX and CAPEX). -- Mikael Abrahamsson email: swmike@swm.pp.se From Dirk.Kutscher@neclab.eu Wed Dec 19 10:03:00 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8A21F8750 for ; Wed, 19 Dec 2012 10:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV1yqMhWKRuv for ; Wed, 19 Dec 2012 10:02:59 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 803E721F859A for ; Wed, 19 Dec 2012 10:02:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BFB38102AEC; Wed, 19 Dec 2012 19:02:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaMSGKBevBw7; Wed, 19 Dec 2012 19:02:58 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 88C13102AE4; Wed, 19 Dec 2012 19:02:43 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.64]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 19 Dec 2012 19:02:43 +0100 From: Dirk Kutscher To: Mikael Abrahamsson , Matt Mathis Thread-Topic: [conex] An interesting video Thread-Index: AQHN3gMkq1AG4vzOUUGOKCrJHfeOr5ggSMkAgAASSzA= Date: Wed, 19 Dec 2012 18:01:40 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249551A2664@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:03:00 -0000 Hi, The video is alright, but the analogy is a bit limited, in my view. Car traffic jams are mostly cases of pathological congestion, i.e., congest= ion makes the systems (close to) unusable. In the Internet, we have transpo= rt protocols to prevent this. What transport protocols today do not enable without network infrastructure= support is capacity sharing that ensures good performance for different ap= plication types and users in the presence of full network utilization. For = example, keeping latency low for my short-lived AJAX interaction although i= t has to share bottlenecks with other users's bulk data transfers. In a street network, you want the trucks to yield for the much faster ambul= ance, so that the ambulance passengers get acceptable quality of experience= and so that the truck drivers can still use all lanes under normal conditi= ons. (I am bad at analogies. ;-) A complete metering and charging infrastructure is indeed non-trivial and e= xpensive to operate. ConEx is essentially intended as not too complex (i.e= ., cost-efficient) network infrastructure support to incentivize such shari= ng. And that does not imply a general toll collect for all traffic as in th= e video. Best regards, Dirk > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: Mittwoch, 19. Dezember 2012 18:04 > To: Matt Mathis > Cc: ConEx IETF list > Subject: Re: [conex] An interesting video >=20 > On Wed, 19 Dec 2012, Matt Mathis wrote: >=20 > > An interesting video, relevant to this group: "Jonas Eliasson: How to > > solve traffic jams" http://youtu.be/CX_Krxq5eUI [TED Talks] >=20 > I have some input. The system he's talking about (Stockholm congestion > charging system) costs around 100MUSD per year to operate. How much > roads could we get for the same amount of money, and would that be a > better investment? The answer seems to have been "no". (I live in > Stockholm, I'm one of the people he's referring to who disliked the syste= m > initially and who now likes it). >=20 > So let's take the analogy to this group. How much would it cost to bring = in an > infrastructure to create the incentives to make people adapt to move some > of their traffic to another part of the day, or not run the traffic at al= l (which is > what a traffic congestion system tries to achieve). >=20 > I don't believe I have seen a system that actually reduces cost by trying= to > intelligently manage congestion or moving traffic spatially, compared to = the > cost of building out the network. A lot of the success of the Internet ha= s > been flat-rate billing so one basically doesn't have to have a lot of sys= tem and > staff to handle usage-based billing. I don't really see how a congestion > management system would fare any better. It adds complexity to the > Network and I don't see how it would really help. > Basically I don't see the incentives for the user to change. >=20 > But I'd gladly be proven wrong, that's why I follow this mailing list. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Wed Dec 19 10:06:45 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F621F859A for ; Wed, 19 Dec 2012 10:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.28 X-Spam-Level: X-Spam-Status: No, score=-106.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5+DaMoD+SEn for ; Wed, 19 Dec 2012 10:06:44 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 79D7C21F84DB for ; Wed, 19 Dec 2012 10:06:44 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8C85633CBB; Wed, 19 Dec 2012 13:06:44 -0500 (EST) Date: Wed, 19 Dec 2012 13:06:44 -0500 From: John Leslie To: Mikael Abrahamsson Message-ID: <20121219180644.GN75059@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:06:45 -0000 Mikael Abrahamsson wrote: > > So let's take the analogy to this group. How much would it cost to bring > in an infrastructure to create the incentives to make people adapt to move > some of their traffic to another part of the day, or not run the traffic > at all (which is what a traffic congestion system tries to achieve). Umm... those aren't the only two possibilities, actually... > I don't believe I have seen a system that actually reduces cost by trying > to intelligently manage congestion or moving traffic spatially, compared > to the cost of building out the network. There are already _many_ multiple paths from sender to receiver: we don't have to build-out for these to exist. Our routing system, however, ignores them because it's optimized for something else. Rather than change the routing system (IMHO), it's more likely we'd build an overlay upon it able to "avoid" congestion by not following the "direct" path. With a system of settlements, ISPs would have a reason to _use_ the overlay system for some portion of traffic not marked for "priority". The "cost" of doing so would be tiny. > A lot of the success of the Internet has been flat-rate billing so one > basically doesn't have to have a lot of system and staff to handle > usage-based billing. Correct! A lot of plain-old-telephone-service companies are suffering big-time from trying to maintain their usage-based billing systems. We don't expect to charge individual end-users here. > I don't really see how a congestion management system would fare any > better. It adds complexity to the Network and I don't see how it would > really help. Basically I don't see the incentives for the user to change. I'm not sure my views are considered "mainstream" anymore, but at first our drafts were written in terms of a "congestion allowance" to the user where the user would see no change in price, merely a limit on how much of his/her traffic would be marked for priority at congestion points. (The ISPs would resolve any imbalance with settlements, or merely drop some congestion-expected traffic in the absence of settlement agreements). Toby and I being told to shut up, we have mostly done so; and now the drafts concentrate on how to catch cheaters, without even discussion of _why_ anybody could be bothered to cheat. > But I'd gladly be proven wrong, that's why I follow this mailing list. :^) It's certainly possible that some actual protocol will come out of this WG yet... -- John Leslie From david.wagner@ikr.uni-stuttgart.de Fri Dec 21 03:37:15 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FE921F86C3 for ; Fri, 21 Dec 2012 03:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOJfSj9QpS-1 for ; Fri, 21 Dec 2012 03:37:14 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 629A921F8781 for ; Fri, 21 Dec 2012 03:37:13 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5A210633B1 for ; Fri, 21 Dec 2012 12:37:12 +0100 (CET) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 168DE59A8A for ; Fri, 21 Dec 2012 12:37:12 +0100 (CET) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: ConEx IETF list Date: Fri, 21 Dec 2012 12:37:11 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201212211237.11324.david.wagner@ikr.uni-stuttgart.de> Subject: [conex] ConEx implementation X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 11:37:15 -0000 Hi, I'd just like to share the information that I'm working on ConEx, focussing on policing mechanisms. Up to now I implemented the TCP modifications and the IPv6 extension (draft-kuehlewind-conex-tcp-modifications / draft-ietf-conex-destopt) in Linux 3.5.4 which I will use in simulations. I expect to get back to you with some results in January. David -- Dipl.-Inf. David Wagner Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart Pfaffenwaldring 47, D-70569 Stuttgart, Germany web: www.ikr.uni-stuttgart.de email: david.wagner@ikr.uni-stuttgart.de phone: +49 711 685-67965 fax: +49 711 685-57965 ------------------------------------------------------------------- From david.wagner@ikr.uni-stuttgart.de Fri Dec 21 04:00:19 2012 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBE221F890E for ; Fri, 21 Dec 2012 04:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh02l61J2g4u for ; Fri, 21 Dec 2012 04:00:18 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 88FC121F883B for ; Fri, 21 Dec 2012 04:00:18 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id B1CF9633B1 for ; Fri, 21 Dec 2012 13:00:17 +0100 (CET) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6790159A8A for ; Fri, 21 Dec 2012 13:00:17 +0100 (CET) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Fri, 21 Dec 2012 13:00:16 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <20121219172008.GM75059@verdi> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201212211300.16617.david.wagner@ikr.uni-stuttgart.de> Subject: Re: [conex] An interesting video X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 12:00:19 -0000 > On Wed, 19 Dec 2012, John Leslie wrote: > > > ~ 1-euro tolls at congestion points reduced traffic 20% and totally > > solved the congestion. > > 2 EUR per passing, and no, it didn't solve the congestion, it made it less > (I guess it would have been a worse talk if he actually would have > presented real figures). > > What he also doesn't talk about is that after that 20% decrease in > traffic, traffic still increased yearly at the same rate so now we have > multi-hour congestion again (basically they bought 5-8 years to implement > a real solution, and then did nothing). I regard the expectation of such incentive-attenuating effects being an important issue for ConEx, too. Such concerns might even hinder a deployment of ConEx. So one of our goals should be to show that the application of ConEx can maintain comparability between network services and thus competition and incentives to continously extend & grow. Of course, ConEx may be a tool to motivate people to distribute their load smoother which will result in lesser pressure on networks and shifted upgrades. At first. In that way I expect a somehow similar effect as of Stockholm's traffic fee. But after this phase, incentives to satisfy growing client demands should reconstitute themselves. David > > But I'm digressing, I'm still interested in how this could be done on the > Internet in a cost-effective way (both OPEX and CAPEX). > -- Dipl.-Inf. David Wagner Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart Pfaffenwaldring 47, D-70569 Stuttgart, Germany web: www.ikr.uni-stuttgart.de email: david.wagner@ikr.uni-stuttgart.de phone: +49 711 685-67965 fax: +49 711 685-57965 -------------------------------------------------------------------