From bob.briscoe@bt.com Mon Jan 31 03:34:55 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F9F3A696D for ; Mon, 31 Jan 2011 03:34:54 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uywuP-trkjtj for ; Mon, 31 Jan 2011 03:34:54 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B6A0D3A6915 for ; Mon, 31 Jan 2011 03:34:53 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 11:38:06 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 11:38:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1296473885426; Mon, 31 Jan 2011 11:38:05 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p0VBc4PE032266; Mon, 31 Jan 2011 11:38:04 GMT Message-Id: <201101311138.p0VBc4PE032266@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 31 Jan 2011 11:38:08 +0000 To: Nandita Dukkipati From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Jan 2011 11:38:06.0411 (UTC) FILETIME=[53D859B0:01CBC13B] X-Mailman-Approved-At: Thu, 03 Feb 2011 17:38:42 -0800 Cc: conex@ietf.org Subject: Re: [conex] State of the WG docs. and action items X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jan 2011 11:34:55 -0000 Nandita, Thanks for this. Also, for concepts-uses, I still have in mind to incorporate responses to the points you made when you first reviewed this. Currently the draft is more aimed at a general audience, while addressing your points would help people who come more from a transport (flow) background. Addressing multiple audiences is always difficult. Do you think we should leave it as is, or attempt to address this specfic audience too? Bob At 01:52 31/01/2011, Nandita Dukkipati wrote: >Hi Everyone, > >Here's the status of the WG docs. along with some action items for >us to make forward progress. > >draft-mathis-conex-abstract-mech-00 >Action items >1. Authors: please submit draft as WG item. >2. The content (not necessarily the text itself) of Appendix A in >draft-moncaster-conex-concepts-uses-02 (ConEx Architectural >Elements) should be included into mechanisms draft, while also using >a terminology coherent with the rest of the draft. > >draft-ietf-conex-concepts-uses >Action items >1. The draft needs to incorporate parts of the mcdysan draft. Please >see ML discussions and meeting minutes of Conex IETF-79, for >specific details on the parts that need to be included and those >that require further discussion. >2. The differential QoS use case requires a good amount of >rewording. It's currently lacking clarity. >3. Include a use case that talks about using Conex to account for >usage inequity over long time-frames. >4. Align terminology with abstract mechanism draft. > >Conex IPv6 format >Action items (for the chairs) >1. What are the different options here, specifically the ones >already expressed in the ML? >2. If we require a bit in the flow label, what is the effort >required and who is willing to do it? > >Conex TCP modifications >Action items >1. We need a draft here! Any takers? Mirja Kuhlewind, would you like >to own this action item? >2. Need to figure out the dependance on Conex IPv6 format. > >Let's get some discussion and activity going in all of these areas! > >-Nandita >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From nanditad@google.com Thu Feb 3 18:09:19 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF393A67A4 for ; Thu, 3 Feb 2011 18:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.226 X-Spam-Level: X-Spam-Status: No, score=-105.226 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN+T9B-6GyJ8 for ; Thu, 3 Feb 2011 18:09:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A346B3A67B1 for ; Thu, 3 Feb 2011 18:09:18 -0800 (PST) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p142CfQj003792 for ; Thu, 3 Feb 2011 18:12:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296785562; bh=v9fZsR9UKlal4vNSaZ6ZJQQ5Mac=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TymwQdAfRIyD/pXViS7ZDBw3xiwt87nokqQj4PsfJuge/OjcD2n99Pu35uf44q69b cDXdyDPVkeLvMUZzCLxWg== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by kpbe15.cbf.corp.google.com with ESMTP id p142CeiV020133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 3 Feb 2011 18:12:40 -0800 Received: by yib2 with SMTP id 2so778653yib.36 for ; Thu, 03 Feb 2011 18:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r/G0bkvyTTMuaksfkBZcNaIASpayKLJYZMHR+MSpOjI=; b=HxUxQ497O+yCqTl7E5fGidb+ZtAM3eIv4nSZDlKr8l4LuzsWWeMvdxQqnuiReN42CL dbNAjpG1vArlH49imDHA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l+3A/nAE0e/vTIQSjHETSxgRjmxSSmlz6eWh9K7srrSANq3xI+0UnUlIbwrf6tfgTa Yj4Hx2shqusYyFgxkYiw== MIME-Version: 1.0 Received: by 10.90.75.4 with SMTP id x4mr14303319aga.177.1296785560230; Thu, 03 Feb 2011 18:12:40 -0800 (PST) Received: by 10.91.52.10 with HTTP; Thu, 3 Feb 2011 18:12:40 -0800 (PST) In-Reply-To: <201101311138.p0VBc4PE032266@bagheera.jungle.bt.co.uk> References: <201101311138.p0VBc4PE032266@bagheera.jungle.bt.co.uk> Date: Thu, 3 Feb 2011 18:12:40 -0800 Message-ID: From: Nandita Dukkipati To: Bob Briscoe Content-Type: multipart/alternative; boundary=0016364d2c6baadc7a049b6b6a01 X-System-Of-Record: true Cc: conex@ietf.org Subject: Re: [conex] State of the WG docs. and action items X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 02:09:20 -0000 --0016364d2c6baadc7a049b6b6a01 Content-Type: text/plain; charset=ISO-8859-1 Hi Bob, I think it is nice to incorporate the points we discussed (about which I owe you a list). However, I think the priorities currently are: P0: the action items listed below. P1: any thing else, including the transport items we discussed. -Nandita On Mon, Jan 31, 2011 at 3:38 AM, Bob Briscoe wrote: > Nandita, > > Thanks for this. > > Also, for concepts-uses, I still have in mind to incorporate responses to > the points you made when you first reviewed this. Currently the draft is > more aimed at a general audience, while addressing your points would help > people who come more from a transport (flow) background. > > Addressing multiple audiences is always difficult. Do you think we should > leave it as is, or attempt to address this specfic audience too? > > > Bob > > > At 01:52 31/01/2011, Nandita Dukkipati wrote: > >> Hi Everyone, >> >> Here's the status of the WG docs. along with some action items for us to >> make forward progress. >> >> draft-mathis-conex-abstract-mech-00 >> Action items >> 1. Authors: please submit draft as WG item. >> 2. The content (not necessarily the text itself) of Appendix A in >> draft-moncaster-conex-concepts-uses-02 (ConEx Architectural Elements) should >> be included into mechanisms draft, while also using a terminology coherent >> with the rest of the draft. >> >> draft-ietf-conex-concepts-uses >> Action items >> 1. The draft needs to incorporate parts of the mcdysan draft. Please see >> ML discussions and meeting minutes of Conex IETF-79, for specific details on >> the parts that need to be included and those that require further >> discussion. >> 2. The differential QoS use case requires a good amount of rewording. It's >> currently lacking clarity. >> 3. Include a use case that talks about using Conex to account for usage >> inequity over long time-frames. >> 4. Align terminology with abstract mechanism draft. >> >> Conex IPv6 format >> Action items (for the chairs) >> 1. What are the different options here, specifically the ones already >> expressed in the ML? >> 2. If we require a bit in the flow label, what is the effort required and >> who is willing to do it? >> >> Conex TCP modifications >> Action items >> 1. We need a draft here! Any takers? Mirja Kuhlewind, would you like to >> own this action item? >> 2. Need to figure out the dependance on Conex IPv6 format. >> >> Let's get some discussion and activity going in all of these areas! >> >> -Nandita >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > --0016364d2c6baadc7a049b6b6a01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bob,

I think it is nice to incorporate the points we = discussed (about which I owe you a list). However, I think the priorities c= urrently are:
P0: the action items listed below.
P1: an= y thing else, including the transport items we discussed.

-Nandita

On Mo= n, Jan 31, 2011 at 3:38 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:
Nandita,

Thanks for this.

Also, for concepts-uses, I still have in mind to incorporate responses to t= he points you made when you first reviewed this. Currently the draft is mor= e aimed at a general audience, while addressing your points would help peop= le who come more from a transport (flow) background.

Addressing multiple audiences is always difficult. Do you think we should l= eave it as is, or attempt to address this specfic audience too?


Bob


At 01:52 31/01/2011, Nandita Dukkipati wrote:
Hi Everyone,

Here's the status of the WG docs. along with some action items for us t= o make forward progress.

draft-mathis-conex-abstract-mech-00
Action items
1. Authors: please submit draft as WG item.
2. The content (not necessarily the text itself) of Appendix A in draft-mon= caster-conex-concepts-uses-02 (ConEx Architectural Elements) should be incl= uded into mechanisms draft, while also using a terminology coherent with th= e rest of the draft.

draft-ietf-conex-concepts-uses
Action items
1. The draft needs to incorporate parts of the mcdysan draft. Please see ML= discussions and meeting minutes of Conex IETF-79, for specific details on = the parts that need to be included and those that require further discussio= n.
2. The differential QoS use case requires a good amount of rewording. It= 9;s currently lacking clarity.
3. Include a use case that talks about using Conex to account for usage ine= quity over long time-frames.
4. Align terminology with abstract mechanism draft.

Conex IPv6 format
Action items (for the chairs)
1. What are the different options here, specifically the ones already expre= ssed in the ML?
2. If we require a bit in the flow label, what is the effort required and w= ho is willing to do it?

Conex TCP modifications
Action items
1. We need a draft here! Any takers? Mirja Kuhlewind, would you like to own= this action item?
2. Need to figure out the dependance on Conex IPv6 format.

Let's get some discussion and activity going in all of these areas!

-Nandita
_______________________________________________
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

--0016364d2c6baadc7a049b6b6a01-- From marcelo@it.uc3m.es Thu Feb 3 23:49:58 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5944D3A6889 for ; Thu, 3 Feb 2011 23:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7B86iaWsb8B for ; Thu, 3 Feb 2011 23:49:57 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 2DE4E3A6892 for ; Thu, 3 Feb 2011 23:49:56 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 601DB6C27CC for ; Fri, 4 Feb 2011 08:53:20 +0100 (CET) Message-ID: <4D4BB06F.8060505@it.uc3m.es> Date: Fri, 04 Feb 2011 08:53:19 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17934.003 Subject: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 07:49:58 -0000 I recommend people to take a look at this thread going on on 6man. It seems apparent from this thread that we either manage to code the conex info in some bits in the main IPv6 header or conex is out of luck. -------- Mensaje original -------- Asunto: Hop-by-Hop Extension Header processed in Slow Path? Fecha: Fri, 4 Feb 2011 06:39:51 +0530 De: Hing-Kam (Kam) Lam Para: ipv6@ietf.org The below white paper from Cisco asserts that most vendors including Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this correct? http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html If Yes, then we should not add support for more sub options with HBH header. Kam -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From john@jlc.net Fri Feb 4 05:05:12 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6643A6BBA for ; Fri, 4 Feb 2011 05:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.364 X-Spam-Level: X-Spam-Status: No, score=-105.364 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLxbrFslE54I for ; Fri, 4 Feb 2011 05:05:11 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 4A5F53A695F for ; Fri, 4 Feb 2011 05:05:11 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4322533C62; Fri, 4 Feb 2011 08:08:36 -0500 (EST) Date: Fri, 4 Feb 2011 08:08:36 -0500 From: John Leslie To: conex@ietf.org Message-ID: <20110204130836.GB16653@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Re: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 13:05:12 -0000 marcelo bagnulo braun wrote: > > I recommend people to take a look at this thread going on on 6man. I recommend people _participate_ in this thread, especially as regards defining non-hop2hop extension headers. > It seems apparent from this thread that we either manage to code the > conex info in some bits in the main IPv6 header or conex is out of luck. In fact, IMHO, we're out-of-luck period without making friends among the 6man folks. (I'm out of time to do anything before late afternoon, otherwise I might have some more-pithy things to say...) -- John Leslie From ajb44.geo@yahoo.com Fri Feb 4 04:20:16 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F263A6BAB for ; Fri, 4 Feb 2011 04:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrKn6lNpYGAz for ; Fri, 4 Feb 2011 04:20:15 -0800 (PST) Received: from web35606.mail.mud.yahoo.com (web35606.mail.mud.yahoo.com [66.163.179.145]) by core3.amsl.com (Postfix) with SMTP id 4CB153A6BA9 for ; Fri, 4 Feb 2011 04:20:14 -0800 (PST) Received: (qmail 1372 invoked by uid 60001); 4 Feb 2011 12:23:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1296822215; bh=v5yeG6UEFTd3XcobiWFe5PX+L1A6LPp4DW8VWVupUag=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=rAGBlsswYwonqa5eJZxsrqt/st99JUZl0wG0Dr+pRgMtJNy6M1k1AyK20UQcJyZ+yj7H2yJgogmRamAMUP8uMJGs8bremXys6gCIxysDA/MOU0q7zX/I65ndfqyyryvgi75hKFe9Enc/P3+PFednmf0nCaBEeOJZZGuNqIY8mug= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=2kw9sZtjeMEOx/jWtABCXg//HgqZhtOP6vLD9d8Wu81lxV0q1JxxcY7Vwyd17yqjwPopQbCJNlakl37y3ScgxTeHTJV65Zi+PQ5xbBC/IWHdvuqJiyk1eN1Gg502xrK4gXlaSQDUEHohAAZu5VtPvfjRb828JVexYT0QBX3qxCc=; Message-ID: <600978.536.qm@web35606.mail.mud.yahoo.com> X-YMail-OSG: .H7FaRUVM1lVWBXLok83slKgPodxqook6nAsNueuutszLfg D88fGW4qXpEolSyYR7Qc.9LidckhW6vI9BOyxbv0RekoVeTmh_owicutIXI_ OLNWbk7Bm.bYnP5cPaqhf8KLjAWXIstdfhHc3QAC5Yf7t1fmZg9Ai67XUQDb luF.chZizM58oohUwgJhzmlCU.WlCIPecwQ53dimPZhaNczDqE9uxb0WnTP. pFB4UnRP8t5kwvafuk8oEToPGnlBIVrWk9V1LneG0ISzFN1AHSbjeVWU7zFS 0Zvl1XUEFUf_T16MiuVLoFeHKUjeY7.9Cyi3nANggEFK1lQ-- Received: from [212.44.20.129] by web35606.mail.mud.yahoo.com via HTTP; Fri, 04 Feb 2011 04:23:35 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.108.291010 Date: Fri, 4 Feb 2011 04:23:35 -0800 (PST) From: Alex Burr To: conex@ietf.org, marcelo bagnulo braun MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 07 Feb 2011 13:19:25 -0800 Subject: Re: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 12:20:16 -0000 marcelo bagnulo braun wrote: > I recommend people to take a look at this thread going on on 6man. > It seems apparent from this thread that we either manage to code the conex >info in some bits in the main IPv6 header or conex is out of luck. > Maybe this is a dumb question, but why isn't a destination option a possibility for conex? It would seem they are a perfect fit. Alex From bob.briscoe@bt.com Fri Feb 4 08:44:34 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423C03A69AF for ; Fri, 4 Feb 2011 08:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx8TN-rQpe-c for ; Fri, 4 Feb 2011 08:44:33 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id E80AF3A695F for ; Fri, 4 Feb 2011 08:44:32 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 16:47:57 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 16:47:56 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 129683807683; Fri, 4 Feb 2011 16:47:56 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p14GlsxM020738; Fri, 4 Feb 2011 16:47:55 GMT Message-Id: <201102041647.p14GlsxM020738@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Feb 2011 16:47:53 +0000 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4D4BB06F.8060505@it.uc3m.es> References: <4D4BB06F.8060505@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 X-OriginalArrivalTime: 04 Feb 2011 16:47:56.0737 (UTC) FILETIME=[4631FB10:01CBC48B] X-Mailman-Approved-At: Mon, 07 Feb 2011 13:19:25 -0800 Cc: conex@ietf.org Subject: Re: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2011 16:44:34 -0000 Marcelo, As I have said before, there is one more option than everyone thinks there is. ConEx could be encoded within an existing v6 extension header (rather than a new one). This is much more feasible than the main v6 header, where there's v little flex. Bob At 07:53 04/02/2011, marcelo bagnulo braun wrote: >I recommend people to take a look at this thread going on on 6man. >It seems apparent from this thread that we either manage to code the >conex info in some bits in the main IPv6 header or conex is out of luck. > > > >-------- Mensaje original -------- >Asunto: Hop-by-Hop Extension Header processed in Slow Path? >Fecha: Fri, 4 Feb 2011 06:39:51 +0530 >De: Hing-Kam (Kam) Lam >Para: ipv6@ietf.org > > > >The below white paper from Cisco asserts that most vendors including >Cisco process Hop-by-Hop extension headers in CPU (slow path). Is this >correct? > >http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html > >If Yes, then we should not add support for more sub options with HBH header. > >Kam >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From suresh.krishnan@ericsson.com Mon Feb 7 14:29:27 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5F63A6F31 for ; Mon, 7 Feb 2011 14:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xj1k0MI-HJ4 for ; Mon, 7 Feb 2011 14:29:26 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 06B873A6B08 for ; Mon, 7 Feb 2011 14:29:25 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p17MSAED022090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Feb 2011 16:29:19 -0600 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.2.234.1; Mon, 7 Feb 2011 16:47:40 -0500 Message-ID: <4D50684E.5050100@ericsson.com> Date: Mon, 7 Feb 2011 16:46:54 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Alex Burr References: <600978.536.qm@web35606.mail.mud.yahoo.com> In-Reply-To: <600978.536.qm@web35606.mail.mud.yahoo.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: "conex@ietf.org" Subject: Re: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 22:29:27 -0000 Hi Alex, On 11-02-04 07:23 AM, Alex Burr wrote: > marcelo bagnulo braun wrote: >> I recommend people to take a look at this thread going on on 6man. >> It seems apparent from this thread that we either manage to code the conex >> info in some bits in the main IPv6 header or conex is out of luck. >> > > Maybe this is a dumb question, but why isn't a destination option a possibility > for conex? It would seem they are a perfect fit. According to the base IPv6 spec Destination options are to be processed only by the ultimate receiver of the datagram (the one in the destination address field). Doing so in an intermediate node would violate the spec. Thanks Suresh From john@jlc.net Mon Feb 7 16:29:16 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF013A6C8B for ; Mon, 7 Feb 2011 16:29:16 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQdChowwKhVf for ; Mon, 7 Feb 2011 16:29:15 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 8994A3A6B0A for ; Mon, 7 Feb 2011 16:29:15 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id F01F633C30; Mon, 7 Feb 2011 19:29:13 -0500 (EST) Date: Mon, 7 Feb 2011 19:29:13 -0500 From: John Leslie To: Suresh Krishnan Message-ID: <20110208002913.GA64333@verdi> References: <600978.536.qm@web35606.mail.mud.yahoo.com> <4D50684E.5050100@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D50684E.5050100@ericsson.com> User-Agent: Mutt/1.4.1i Cc: Alex Burr , "conex@ietf.org" Subject: Re: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 00:29:16 -0000 Suresh Krishnan wrote: > On 11-02-04 07:23 AM, Alex Burr wrote: >>marcelo bagnulo braun wrote: >> >>> I recommend people to take a look at this thread going on on 6man. I strongly recommend not merely looking, but participating. The "Hop-by-Hop Extension Header processed in Slow Path" is actively discussing (well, "actively" by 6MAN standards) whether it makes sense to define a header that isn't Hop-by-Hop but is intended to be acted upon by "middleboxes". >> Maybe this is a dumb question, but why isn't a destination option a >> possibility for conex? It would seem they are a perfect fit. Hardly "perfect"... > According to the base IPv6 spec Destination options are to be processed > only by the ultimate receiver of the datagram (the one in the > destination address field). Doing so in an intermediate node would > violate the spec. I feel unable to say whether this would "violate" any spec. I'm pretty sure some folks active in 6MAN would disagree with that statement (and others would just as strongly agree). The intent seems to be clear at the time of writing RFC 2460 that routers along the way wouldn't take the time to process a Destination Options header unless the packet were addressed to them. Nonetheless, I didn't read that as a prohibition: least of all a prohibition of such a header being examined by middleboxes. (And, of course, 2460 isn't the whole story.) But that question cannot be resolved here. 6MAN is the WG charged to address such issues. I'm not going to go into details here, but I recommend reviewing my presentation to ICCRG in November, at http://pfld.net/2010/slides/iccrg-leslie.pdf and actively participating on 6MAN, whether by stating what you'd like ConEx to be able to do with an intermediate class of options or simply by asking a question. -- John Leslie From lars.eggert@nokia.com Thu Feb 17 05:29:53 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B158B3A6CAE for ; Thu, 17 Feb 2011 05:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UREfsF7LZzq for ; Thu, 17 Feb 2011 05:29:47 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 426A73A6C8B for ; Thu, 17 Feb 2011 05:29:47 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1HDUFfd002457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 15:30:16 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-69--332854041; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 17 Feb 2011 15:30:09 +0200 Message-Id: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> To: conex@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 17 Feb 2011 15:30:09 +0200 (EET) X-Nokia-AV: Clean Subject: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 13:29:56 -0000 --Apple-Mail-69--332854041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, folks, this WG has become very quiet very quickly after being chartered. Given = the significant community building that will be required for CONEX = mechanisms to succeed in the broader IETF and ISP space, this is not a = good sign. Lars= --Apple-Mail-69--332854041 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNzEzMzAwOVowIwYJKoZIhvcNAQkE MRYEFNTHDk1gw52/e9dZjm74ETvJOMdtMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AIOBAWhudhu+17e58wdkHSZGY8bvaW1u1Yw1qOWpHNAx7LXTBKeu+qxPlbGeY14zyJf6WRTnvniV pB8v7irBF0xnR3u2Qbo8NiJ7upyZ1Wn3t8w2Ha658+Lx2dYWV37u3XNu5CFXzHZMfFKZnGfRHr3F g7SJNqgkKEu2FOlloUPE9k8sWbP8nWyOOUV1aUntnIEPcssWuITaVgjCTNjFNXGI0BLmKRn/XZL2 CHtVE7cE9kWaEjK26GD515dknAPoDpq1IVLJmQFvWZJDvZiJWqCDYBXQSZB+BYMx6+H+OkUjaN7d NA5MLU9/MA+qLPwd4dcQVdDorVS6fplOfbRDGggAAAAAAAA= --Apple-Mail-69--332854041-- From toby@moncaster.com Thu Feb 17 05:59:35 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9953A6CAC for ; Thu, 17 Feb 2011 05:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEr8pfAKTCzr for ; Thu, 17 Feb 2011 05:59:35 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 969683A6B6C for ; Thu, 17 Feb 2011 05:59:34 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LrXBZ-1QD3j20GmD-013j6K; Thu, 17 Feb 2011 15:00:02 +0100 From: "Toby Moncaster" To: "'Lars Eggert'" , References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> In-Reply-To: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> Date: Thu, 17 Feb 2011 14:00:00 -0000 Message-ID: <003b01cbceaa$f85540d0$e8ffc270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvOptq+ldctuBvdQyusVJv1UKUesAAA0QJw Content-Language: en-gb X-Provags-ID: V02:K0:HODaH5s6Qeme9Hkx9GTFTxyOEYqJNpP18pkaqENm/tH RbjRNDYoapG16UIZxVGoboOzyjIMdQzsxQfy7Jev8wXlVFIrjZ X1lguwvsJYxe0TMfe6vZ4vpDlVAzFIDs7DFSx2N5lMiiNyA1w8 cb4T/M/oDW+UxtO1V7HGW5ivvRmvXMinUqF8gqRvucxrexnxa3 BOUPYYD3dF0glywbg80bCPfAzY1hnYi8fZJSgvq7tI= Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 13:59:35 -0000 Hi Lars, I know things have been quiet over the past couple of months. There has been some off-list activity among authors, and we (the authors of the concepts and use cases draft) are intending to post an update in a week or two. Before that we will be starting a conversation on-list about which elements of Dave McDysan's draft will be incorporated into the existing draft. What worries me is the relatively limited input from outside the small group of people that were active during the chartering of the group. That may be down to a lack of prodding by us authors or may be a sign that people are getting spread rather thin and are choosing not to commit cycles to ConEx. Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: 17 February 2011 13:30 > To: conex@ietf.org > Subject: [conex] WG energy > > Hi, folks, > > this WG has become very quiet very quickly after being chartered. Given > the significant community building that will be required for CONEX > mechanisms to succeed in the broader IETF and ISP space, this is not a > good sign. > > Lars From carlberg@g11.org.uk Thu Feb 17 06:18:14 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D251A3A6CBB for ; Thu, 17 Feb 2011 06:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0CzcCSaiYc3 for ; Thu, 17 Feb 2011 06:18:14 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E966F3A6B6C for ; Thu, 17 Feb 2011 06:18:13 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:54235 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Pq4gk-0004kU-Nu; Thu, 17 Feb 2011 14:18:34 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <003b01cbceaa$f85540d0$e8ffc270$@com> Date: Thu, 17 Feb 2011 09:18:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F096332-A641-4AE4-A4E2-519FF3D28F84@g11.org.uk> References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> To: Toby Moncaster X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 14:18:14 -0000 One thing that may be helpful is if the "small group of people" post = some open issues to the list for input or discussion. I know its more = comfortable to have a consensus voice amoung authors, but I find it = refreshing to see various opinions and open thought on lists -- = regardless of where they come from. Otherwise, the rest of us will just = be lurkers and remain quiet :-) cheers, -ken On Feb 17, 2011, at 9:00 AM, Toby Moncaster wrote: > Hi Lars, >=20 > I know things have been quiet over the past couple of months. There = has been > some off-list activity among authors, and we (the authors of the = concepts > and use cases draft) are intending to post an update in a week or two. > Before that we will be starting a conversation on-list about which = elements > of Dave McDysan's draft will be incorporated into the existing draft. >=20 > What worries me is the relatively limited input from outside the small = group > of people that were active during the chartering of the group. That = may be > down to a lack of prodding by us authors or may be a sign that people = are > getting spread rather thin and are choosing not to commit cycles to = ConEx. >=20 > Toby >=20 >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On = Behalf >> Of Lars Eggert >> Sent: 17 February 2011 13:30 >> To: conex@ietf.org >> Subject: [conex] WG energy >>=20 >> Hi, folks, >>=20 >> this WG has become very quiet very quickly after being chartered. = Given >> the significant community building that will be required for CONEX >> mechanisms to succeed in the broader IETF and ISP space, this is not = a >> good sign. >>=20 >> Lars >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From cait@asomi.com Thu Feb 17 08:06:47 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8374D3A6F46 for ; Thu, 17 Feb 2011 08:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APNqKMTDm-BJ for ; Thu, 17 Feb 2011 08:06:46 -0800 (PST) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by core3.amsl.com (Postfix) with ESMTP id 80B393A6D2B for ; Thu, 17 Feb 2011 08:06:46 -0800 (PST) Received: (qmail 14746 invoked from network); 17 Feb 2011 16:07:17 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 17 Feb 2011 16:07:17 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: <003b01cbceaa$f85540d0$e8ffc270$@com> Date: Thu, 17 Feb 2011 08:07:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> To: Toby Moncaster X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 16:06:47 -0000 As of the first draft the proposal was a bit too vague to champion it = internally with your employer. In particular, the degree to which an implementation could be = synergistic with 802.1 DCB=20 ccongestion control is still very vague. An ideal conex draft, in my evaluation, would allow forwarding elements = to implement=20 *both* DCB and Conex, and suggest a method by which DCB congestion could = be reporrted to the IP stack as though it had been reported by a CONEX = device. On Feb 17, 2011, at 6:00 AM, Toby Moncaster wrote: > Hi Lars, >=20 > I know things have been quiet over the past couple of months. There = has been > some off-list activity among authors, and we (the authors of the = concepts > and use cases draft) are intending to post an update in a week or two. > Before that we will be starting a conversation on-list about which = elements > of Dave McDysan's draft will be incorporated into the existing draft. >=20 > What worries me is the relatively limited input from outside the small = group > of people that were active during the chartering of the group. That = may be > down to a lack of prodding by us authors or may be a sign that people = are > getting spread rather thin and are choosing not to commit cycles to = ConEx. >=20 > Toby >=20 >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On = Behalf >> Of Lars Eggert >> Sent: 17 February 2011 13:30 >> To: conex@ietf.org >> Subject: [conex] WG energy >>=20 >> Hi, folks, >>=20 >> this WG has become very quiet very quickly after being chartered. = Given >> the significant community building that will be required for CONEX >> mechanisms to succeed in the broader IETF and ISP space, this is not = a >> good sign. >>=20 >> Lars >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From john@jlc.net Thu Feb 17 10:03:50 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CE13A6DA0 for ; Thu, 17 Feb 2011 10:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.845 X-Spam-Level: X-Spam-Status: No, score=-106.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNR5qB4TxziR for ; Thu, 17 Feb 2011 10:03:49 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 437173A6CB8 for ; Thu, 17 Feb 2011 10:03:49 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4B36933C36; Thu, 17 Feb 2011 13:04:11 -0500 (EST) Date: Thu, 17 Feb 2011 13:04:11 -0500 From: John Leslie To: Caitlin Bestler Message-ID: <20110217180411.GK86652@verdi> References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> <34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 17 Feb 2011 18:03:50 -0000 Caitlin Bestler wrote: > > As of the first draft the proposal was a bit too vague to champion it > internally with your employer. Speaking as an author, I don't believe that was our aim. It's a critical-path item for IESG approval to submit anything else. Nonetheless, > In particular, the degree to which an implementation could be synergistic > with 802.1 DCB ccongestion control is still very vague. Hmm... I suspect most of us on this list aren't terribly familiar with 802.1Qau. (That is what you're referring to, right?) > An ideal conex draft, in my evaluation, would allow forwarding elements > to implement *both* DCB and Conex, and suggest a method by which DCB > congestion could be reported to the IP stack as though it had been > reported by a CONEX device. I'm guessing here... We've been writing in terms of something very like ECN to mark congestion, which marks according to a queue filling. 802.1Qau has an out-of-band mechanism to report "percent congestion" from receiving switch to sender (if I read it correctly, I presume that to be between two routers). This does sound like promising information, but it's not immediately clear how it should get reported to a Layer 3 device. In any case, I don't believe we're wedded to ECN as the congestion- sensing mechanism -- and I, at least, would want ConEx to be extensible to new congestion-sensing mechanisms. Perhaps Caitlin could expand a bit? -- John Leslie From swmike@swm.pp.se Thu Feb 17 19:44:37 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EFE3A6DE4 for ; Thu, 17 Feb 2011 19:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5fCIDhH1spi for ; Thu, 17 Feb 2011 19:44:36 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6EC023A6D72 for ; Thu, 17 Feb 2011 19:44:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2581E9C; Fri, 18 Feb 2011 04:45:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 244B99A; Fri, 18 Feb 2011 04:45:06 +0100 (CET) Date: Fri, 18 Feb 2011 04:45:06 +0100 (CET) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <003b01cbceaa$f85540d0$e8ffc270$@com> Message-ID: References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 03:44:37 -0000 On Thu, 17 Feb 2011, Toby Moncaster wrote: > What worries me is the relatively limited input from outside the small > group of people that were active during the chartering of the group. > That may be down to a lack of prodding by us authors or may be a sign > that people are getting spread rather thin and are choosing not to > commit cycles to ConEx. If you want operational input, I suggest taking things to NANOG and other equivalent operational forums. Fred Baker has successfully done this with IPv6 stuff. You have to face it, operators don't really come to IETF that much, so if you want input, you have to go to them. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Fri Feb 18 01:53:04 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E303A6EA1 for ; Fri, 18 Feb 2011 01:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz0jL25gYuyi for ; Fri, 18 Feb 2011 01:53:03 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 38CF43A68A3 for ; Fri, 18 Feb 2011 01:53:03 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M7Fcg-1Q20mw3CNi-00xAu4; Fri, 18 Feb 2011 10:53:33 +0100 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> In-Reply-To: Date: Fri, 18 Feb 2011 09:53:32 -0000 Message-ID: <001101cbcf51$b4412560$1cc37020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvPHjvVssWoa6+ZRaS5W8R+U7iukQAMu6nA Content-Language: en-gb X-Provags-ID: V02:K0:i+hZNvCNgUmVPuRa5ZxXmNAOPQ1HGyHMa2fqNmz+Axe P54LPgwHYHWITT3KpLhzddqCnt6XbCdcroZ1Tck6GAwRtZ0TeK 7ckxPRqnouy2BSaxRm15gvFQQxxFgCak8S+eLhr4fTf3QWXBC5 hVdbns+h+ARrnRv3v2WX/aIdhXw6TRtxpBbaum2DtyNkWi2SrC vLyeTBp0vNeBA7EHBLV9kYqPt8Ggn/BWzVu++7pVnk= Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 18 Feb 2011 09:53:04 -0000 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: 18 February 2011 03:45 > To: Toby Moncaster > Cc: 'Lars Eggert'; conex@ietf.org > Subject: Re: [conex] WG energy > > On Thu, 17 Feb 2011, Toby Moncaster wrote: > > > What worries me is the relatively limited input from outside the > small > > group of people that were active during the chartering of the group. > > That may be down to a lack of prodding by us authors or may be a sign > > that people are getting spread rather thin and are choosing not to > > commit cycles to ConEx. > > If you want operational input, I suggest taking things to NANOG and > other > equivalent operational forums. Fred Baker has successfully done this > with > IPv6 stuff. > > You have to face it, operators don't really come to IETF that much, so > if > you want input, you have to go to them. Not sure it's lack of operators that is the real problem... After all 3 of the authors on the concepts and use cases draft work for operators. I think where the issue comes is in convincing people that there is a roadmap to adoption that can happen over sensible timescales. In the current climate companies are (understandably) reluctant to stick their necks out too far and so are tending to be fairly conservative in what they choose to invest in. The worry I have is that the Internet is still firmly following Moore's Law and if people are too conservative they will find they have got left far behind. Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From marcelo@it.uc3m.es Mon Feb 21 02:39:40 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CEE3A7080 for ; Mon, 21 Feb 2011 02:39:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+TEmdCOXgUx for ; Mon, 21 Feb 2011 02:39:39 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id C510A3A707E for ; Mon, 21 Feb 2011 02:39:39 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 5359FC07C07 for ; Mon, 21 Feb 2011 11:40:19 +0100 (CET) Message-ID: <4D624113.5010800@it.uc3m.es> Date: Mon, 21 Feb 2011 11:40:19 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17968.006 Subject: [conex] Presentation slot requests for Prague IETF meeting X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 21 Feb 2011 10:39:40 -0000 Hi, CONEX WG will meet at the prague IETF. Please send the request for slots to the chairs. Regards, marcelo From cait@asomi.com Tue Feb 22 20:41:09 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908FE3A69DE for ; Tue, 22 Feb 2011 20:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76OEzlgh2S7i for ; Tue, 22 Feb 2011 20:41:08 -0800 (PST) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by core3.amsl.com (Postfix) with ESMTP id 7A3A63A69D1 for ; Tue, 22 Feb 2011 20:41:08 -0800 (PST) Received: (qmail 16489 invoked from network); 23 Feb 2011 04:41:54 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 23 Feb 2011 04:41:53 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: <20110217180411.GK86652@verdi> Date: Tue, 22 Feb 2011 20:41:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com> <003b01cbceaa$f85540d0$e8ffc270$@com> <34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> <20110217180411.GK86652@verdi> To: John Leslie X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 23 Feb 2011 04:41:09 -0000 On Feb 17, 2011, at 10:04 AM, John Leslie wrote: > Caitlin Bestler wrote: >>=20 >> As of the first draft the proposal was a bit too vague to champion it >> internally with your employer. >=20 > Speaking as an author, I don't believe that was our aim. It's a > critical-path item for IESG approval to submit anything else. >=20 > Nonetheless, >=20 >> In particular, the degree to which an implementation could be = synergistic >> with 802.1 DCB ccongestion control is still very vague. >=20 > Hmm... >=20 > I suspect most of us on this list aren't terribly familiar with > 802.1Qau. (That is what you're referring to, right?) >=20 >> An ideal conex draft, in my evaluation, would allow forwarding = elements >> to implement *both* DCB and Conex, and suggest a method by which DCB >> congestion could be reported to the IP stack as though it had been >> reported by a CONEX device. >=20 > I'm guessing here...=20 >=20 > We've been writing in terms of something very like ECN to mark > congestion, which marks according to a queue filling. >=20 > 802.1Qau has an out-of-band mechanism to report "percent congestion" > from receiving switch to sender (if I read it correctly, I presume = that > to be between two routers). This does sound like promising = information, > but it's not immediately clear how it should get reported to a Layer 3 > device. >=20 > In any case, I don't believe we're wedded to ECN as the congestion- > sensing mechanism -- and I, at least, would want ConEx to be = extensible > to new congestion-sensing mechanisms. >=20 > Perhaps Caitlin could expand a bit? >=20 > -- > John Leslie Each protocol has its own constraints about where the information is = encoded and how often it is sent. But I think it would be of great value to be measuring the same things = in 802.1Qau congestion reporting and IETF congestion reporting. Certainly there are many implementations = where a packet may be assigned to an output queue based on L2 factors or on L3 factors, but they are = frequently the same queues. The network stacks on end stations could really benefit from having = uniform handling by a device that could report congestion using either 802.1Qau or conex. Is 802.1Qau used = universally when there is no "routing" involved, and never when a frame is "routed"? That would seem a bit = extreme when the "routing" was essentially just relabeling the VLAN tag and the full 802.1Qau information was = available. On the other hand a conex aware forwarding element would know when a = flow was not confined to the scope required for 802.1Qau, and could properly provide feedback to the true = endpoints rather than just the local L2 endpoints. The actual source of a flow is actually capable of slowing = the flow down, while an ingress router could generally only drop packets or do ECN marking. The other area where convergence would be useful is coming up with an = abstract way to report "congestion detected" with more precision than just an ECN bit, so that L4 can = utilize this information wihtout having to learn the specifics of L2 congestion control protocols. -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From rs@netapp.com Thu Feb 24 02:22:14 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FB13A6A72 for ; Thu, 24 Feb 2011 02:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMlaxx-0SCjw for ; Thu, 24 Feb 2011 02:21:44 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 179233A6A6B for ; Thu, 24 Feb 2011 02:21:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,215,1297065600"; d="scan'208";a="242802827" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 24 Feb 2011 02:21:30 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p1OALTpX002279; Thu, 24 Feb 2011 02:21:29 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Feb 2011 10:21:30 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2011 10:21:29 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D12CDA8@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110217180411.GK86652@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] WG energy Thread-Index: AcvOzSBNFRZoUgFSQdG0t3uhid37kgEhkBSA References: <2F246B0F-0AD2-463B-9C3D-E17F3709FC76@nokia.com><003b01cbceaa$f85540d0$e8ffc270$@com><34EEDAE3-A7CF-413C-9182-A13608473622@asomi.com> <20110217180411.GK86652@verdi> From: "Scheffenegger, Richard" To: "John Leslie" , "Caitlin Bestler" X-OriginalArrivalTime: 24 Feb 2011 10:21:30.0017 (UTC) FILETIME=[9A184910:01CBD40C] Cc: conex@ietf.org Subject: Re: [conex] WG energy X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 10:22:16 -0000 >> In particular, the degree to which an implementation could be synergistic >> with 802.1 DCB ccongestion control is still very vague. > > Hmm... > > I suspect most of us on this list aren't terribly familiar with > 802.1Qau. (That is what you're referring to, right?) > >> An ideal conex draft, in my evaluation, would allow forwarding elements >> to implement *both* DCB and Conex, and suggest a method by which DCB >> congestion could be reported to the IP stack as though it had been >> reported by a CONEX device. > > I'm guessing here...=20 > > We've been writing in terms of something very like ECN to mark > congestion, which marks according to a queue filling. > > 802.1Qau has an out-of-band mechanism to report "percent congestion" > from receiving switch to sender (if I read it correctly, I presume that > to be between two routers). This does sound like promising information, > but it's not immediately clear how it should get reported to a Layer 3 > device. Isn't 802.1Qau supposed to throttle / stop all traffic of an offending flow (as classified by 802.1Qau - which could be of variable granularity depending on the capabilities of the device IIRC) when congestion is experienced? Also, the sender in the 802.1Qau case is a L2 MAC device - which is doing the throttling.=20 The only thing a L3+ sender would notice would either be queues building at the L3/L2 interface, or calls to send data would block instead of immediately return.=20 Obvioulsy, filling some queue right in the sender (be it a hardware or software queue) is a bad thing (www.bufferbloat.net), so there might be some merit in signaling this between layers. However, as all that is required happens within the same host, it's more of an API question between device driver and software stack, rather than a protocol issue concerning the explicit signaling in a L3 header...=20 Of course, if the egress side of a Router is 802.1Qau, but the ingress side is not, the router may want to inform the flow - but standard ECN marking (available with IPv4 and IPv6) should do that...=20 Or am I missing something more? Best regards, Richard =20 From toby@moncaster.com Thu Feb 24 03:23:33 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4F53A69E7 for ; Thu, 24 Feb 2011 03:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7RMfTKyoZuG for ; Thu, 24 Feb 2011 03:23:31 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id F30DF3A69C4 for ; Thu, 24 Feb 2011 03:23:30 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M5tFN-1QHDjf3wnh-00xtrr; Thu, 24 Feb 2011 12:24:19 +0100 From: "Toby Moncaster" To: Date: Thu, 24 Feb 2011 11:24:18 -0000 Message-ID: <002a01cbd415$61222320$23666960$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvUFWBmBSTz8ciaTn6tiKMAWo573g== Content-Language: en-gb X-Provags-ID: V02:K0:5iSY1HrnVuo1WbhfBOMF3pnzF3fcKlgLbDaXhUMW/NZ sCfcvG68E6ck53m2XlE310TqETTkSPhrsP3RC1bJX6npKcifGL qsGs/3j5GdqGbM8jTe+AWtbuJblBETGEirS+N0VsXpKvuDlWr4 IZAAyc41S1MvH6B7F2loLxfMOPzU7FEYuZKFs4NcHtkoG2HgHJ b730chg9HILtJPlV2GLR7xA4FTpo/PMH/bmp3MTkls= Subject: [conex] Merge of Use Cases drafts - advance warning! X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 11:23:33 -0000 All, At the Beijing meeting there was a lot of discussion regarding which use cases from draft-mcdysan-conex-other-usecases should be incorporated into draft-ietf-conex-concepts-uses. The meeting seemed to reach the following consensus: -- Inequity of Heavy versus Light Users. This sparked a lot of discussion and _will_ appear in some form in the next version of the Concepts and Use Cases draft. -- Usage Tier/ Volume Feedback. This was of interest, but it was felt that it would be best if Dave McDysan pursues it as an individual draft (at least for now). -- Feedback on Time of Day, Day of Week Charging. This got a cautious "thumbs up", but needs care to avoid overt talk of charging and billing issues. It _will_ be included in some form in the next version of the Concepts and Use Cases draft. -- Recharging for Implementing Congestion Pricing. This seemed to cause some confusion and the only clear views expressed in the meeting were negative, so it _will not_ be included in the combined draft. I am going to start two discussions over the next couple of days to try and reach rough consensus on what actually needs to go into the combined draft. The first will explore the issues raised by Dave's "Inequity of Heavy versus Light Users" use case. The second will explore the "Feedback on Time of Day, Day of Week Charging" use case. Keep your eyes peeled and please contribute to the discussions when they start! Best Regards, Toby Moncaster (on behalf of all the use case authors) PS. I hope the discussions will rumble on for some time, but the draft submission cut-off means we will try and capture the essence of the discussions after about a week, ready to go into the revised draft. From toby@moncaster.com Thu Feb 24 11:34:59 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8290E3A680B for ; Thu, 24 Feb 2011 11:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, GB_PAYLESS=0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m1GGfakNJ6L for ; Thu, 24 Feb 2011 11:34:58 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 397413A67A8 for ; Thu, 24 Feb 2011 11:34:58 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LyBrp-1Q4wyM0AWD-0169S5; Thu, 24 Feb 2011 20:35:47 +0100 From: "Toby Moncaster" To: Date: Thu, 24 Feb 2011 19:35:47 -0000 Message-ID: <006001cbd45a$0995aba0$1cc102e0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CBD45A.0995D2B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvUWgk/5eTxGmL8T6CQUm/36hMGaA== Content-Language: en-gb X-Provags-ID: V02:K0:nfBUvNyt8PwvS0Efg1SwFxO9iWeXP3WgbHuvD0i4Sz9 At9ibqoyLvMSA35010Q9K6O2oWkXdGykYv8UGwbCIPC1yqS61/ XSlENYv01W8f1zB3z1Mpa8Sv5vODDhDwGiOywMbXWA09vs77eY JUhRoKtYCecoZIFbLjxUBHk4JDd73OfXz90BYe8ezFzs7yL6Sm 5ol6XzYapt4QJUQnWwaNcqxEE8kL9K8oasFngCGtrg= Subject: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 19:34:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0061_01CBD45A.0995D2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "Inequity of Heavy versus Light Users" use case It was agreed that the "Inequity" use case from draft-mcdysan-conex-other-usecases should be included in the WG Concepts and Use Cases draft. As mentioned in my earlier email, the hope is to trigger a discussion round the issues raised and to come to a consensus on what actually needs to appear in the revised draft. >From the discussion at Beijing it is apparent that the key aspect for defining heavy and light users here is timescales. The worry people have is that 20% of users are taking 80% of capacity, often without paying any extra for doing so. Quoting from Dave McDysan's draft: During non-peak periods, the resources of a service or content provider are underutilized and the marginal cost of capacity is small. The access network is provisioned and traffic engineered for peak capacity of all users, and when congested, heavy users create 16 times the congestion of small users. However, during peak use periods, a heavy user may send at near the bandwidth tier while light users may send intermittently. There is a need for a means for service providers to equitably assign costs to heavy versus light users. For example, the light users may pay less if they were charged by volume, as described in another use case. The proposal in the draft was to introduce a "congestion measure of burstiness (e.g., ratio of peak rate to average rate over a longer interval than the tiered bandwidth shaper or policer)". The assertion is that this measure of burstiness would allow heavy users to be identified and hence free up capacity for the lighter users. So there are three questions for discussion: 1) is there a need for a new "congestion measure of burstiness" that would tag users as "heavy" or "light" over long timescales? 2) how would the system be expected to react differently to heavy and light users? 3) can the same effect be achieved using current measures of congestion and current policing mechanisms? There is also some question as to whether this is the best title for this use case. At its heart the use case is really concerned with timescales and so it might be better to include a section on timescales in the draft. Toby ------=_NextPart_000_0061_01CBD45A.0995D2B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"Inequity of Heavy versus Light Users" = use case

 

It was agreed that the "Inequity" use = case from draft-mcdysan-conex-other-usecases should be included in the = WG Concepts and Use Cases draft. As mentioned in my earlier email, the = hope is to trigger a discussion round the issues raised and to come to a = consensus on what actually needs to appear in the revised = draft.

 

From the discussion at Beijing it is apparent that = the key aspect for defining heavy and light users here is timescales. = The worry people have is that 20% of users are taking 80% of capacity, = often without paying any extra for doing so. Quoting from Dave McDysan's = draft:

 

   During non-peak periods, the resources = of a service or content

   provider are underutilized and the = marginal cost of capacity is

   small.

 

   The access network is provisioned and = traffic engineered for peak

   capacity of all users, and when = congested, heavy users create 16

   times the congestion of small = users.

 

   However, during peak use periods, a = heavy user may send at near the

   bandwidth tier while light users may = send intermittently. There is a

   need for a means for service providers = to equitably assign costs to

   heavy versus light users. For example, = the light users may pay less

   if they were charged by volume, as = described in another use case.

 

The = proposal in the draft was to introduce a "congestion measure of = burstiness (e.g., ratio of peak rate to average rate over a longer = interval than the tiered bandwidth shaper or policer)". The = assertion is that this measure of burstiness would allow heavy users to = be identified and hence free up capacity for the lighter = users.

 

So there are three questions for discussion: =

 

1) is there a need for a new "congestion = measure of burstiness" that would tag users as "heavy" or = "light" over long timescales?

 

2) how = would the system be expected to react differently to heavy and light = users?

 

3) can the same effect be achieved using current = measures of congestion and current policing mechanisms?

 

There = is also some question as to whether this is the best title for this use = case. At its heart the use case is really concerned with timescales and = so it might be better to include a section on timescales in the = draft.

 

Toby

 

 

------=_NextPart_000_0061_01CBD45A.0995D2B0-- From stuart.venters@adtran.com Thu Feb 24 13:54:38 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A903A680D for ; Thu, 24 Feb 2011 13:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_PAYLESS=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5UT9lvY-K3Y for ; Thu, 24 Feb 2011 13:54:36 -0800 (PST) Received: from p02c12o143.mxlogic.net (p02c12o143.mxlogic.net [208.65.145.76]) by core3.amsl.com (Postfix) with ESMTP id AE28A3A6807 for ; Thu, 24 Feb 2011 13:54:34 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c12o143.mxlogic.net(mxl_mta-6.9.0-1) over TLS secured channel with ESMTP id dc3d66d4.0.20780.00-327.48158.p02c12o143.mxlogic.net (envelope-from ); Thu, 24 Feb 2011 14:55:26 -0700 (MST) X-MXL-Hash: 4d66d3ce4b6868be-1aeb451e260a749f15117561fa7664a9f71579d6 Received: from corp-exfr1.corp.adtran.com (172.23.101.21) by ex-hc3.corp.adtran.com (172.22.50.73) with Microsoft SMTP Server id 14.1.270.1; Thu, 24 Feb 2011 15:55:24 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr1.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Feb 2011 15:55:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD46D.897FA0C4" Date: Thu, 24 Feb 2011 15:55:23 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB91B@EXV1.corp.adtran.com> In-Reply-To: <006001cbd45a$0995aba0$1cc102e0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvUWgk/5eTxGmL8T6CQUm/36hMGaAAElixQ From: STUART VENTERS To: X-OriginalArrivalTime: 24 Feb 2011 21:55:24.0525 (UTC) FILETIME=[8A3209D0:01CBD46D] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] X-AnalysisOut: [v=1.0 c=1 a=G9T4uwCCN8UA:10 a=BLceEmwcHowA:10 a=J+LXdEUA8t] X-AnalysisOut: [8MtBPt16/Qbg==:17 a=48vgC7mUAAAA:8 a=k1EH8iZRjNIZSONgo68A:] X-AnalysisOut: [9 a=0qDp9SCSFqfRG6uY0PkA:7 a=WpDRftOUGxtRk-KPJyLjdOLnuVsA:] X-AnalysisOut: [4 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=SSmOFEACAAAA:8 a=y] X-AnalysisOut: [MhMjlubAAAA:8 a=j12IqGxtCpiyLI35v0wA:9 a=WGng1pI_deU25Qrvp] X-AnalysisOut: [BgA:7 a=-pV-pG2PuOjO8Fy_xKUttGZ4UJMA:4] Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 21:54:39 -0000 ------_=_NextPart_001_01CBD46D.897FA0C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me make sure I understand this use case and it's desired outcome: =20 Consider 2 users A, and B. A sends at a low rate all the time. B sends only a congestion causing bunch during busy times. A sends many more bytes per month than B =20 Which is the 'heavy' user (I think B)? =20 Are we looking for a way for service providers to determine 'equitable' = costs for these behaviors, or a way to make the system forwarding behavior for these two load is = somehow 'equitable'? =20 -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]On Behalf Of = Toby Moncaster Sent: Thursday, February 24, 2011 1:36 PM To: conex@ietf.org Subject: [conex] Discussion of new Use Cases pt 1 "Inequity of Heavy versus Light Users" use case =20 It was agreed that the "Inequity" use case from = draft-mcdysan-conex-other-usecases should be included in the WG Concepts = and Use Cases draft. As mentioned in my earlier email, the hope is to = trigger a discussion round the issues raised and to come to a consensus = on what actually needs to appear in the revised draft. =20 >From the discussion at Beijing it is apparent that the key aspect for = defining heavy and light users here is timescales. The worry people have = is that 20% of users are taking 80% of capacity, often without paying = any extra for doing so. Quoting from Dave McDysan's draft: =20 During non-peak periods, the resources of a service or content provider are underutilized and the marginal cost of capacity is small. =20 The access network is provisioned and traffic engineered for peak capacity of all users, and when congested, heavy users create 16 times the congestion of small users. =20 However, during peak use periods, a heavy user may send at near the bandwidth tier while light users may send intermittently. There is a need for a means for service providers to equitably assign costs to heavy versus light users. For example, the light users may pay less if they were charged by volume, as described in another use case. =20 The proposal in the draft was to introduce a "congestion measure of = burstiness (e.g., ratio of peak rate to average rate over a longer = interval than the tiered bandwidth shaper or policer)". The assertion is = that this measure of burstiness would allow heavy users to be identified = and hence free up capacity for the lighter users. =20 So there are three questions for discussion:=20 =20 1) is there a need for a new "congestion measure of burstiness" that = would tag users as "heavy" or "light" over long timescales? =20 2) how would the system be expected to react differently to heavy and = light users? =20 3) can the same effect be achieved using current measures of congestion = and current policing mechanisms? =20 There is also some question as to whether this is the best title for = this use case. At its heart the use case is really concerned with = timescales and so it might be better to include a section on timescales = in the draft. =20 Toby =20 =20 ------_=_NextPart_001_01CBD46D.897FA0C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Let me=20 make sure I understand this use case and it's desired=20 outcome:
 
Consider 2 users A, and = B.
   A sends at a low rate all the=20 time.
   B sends only a congestion = causing bunch=20 during busy times.
   A sends many more bytes per = month than=20 B
 
Which=20 is the 'heavy' user (I think B)?
 
Are we=20 looking for a way for service providers to determine 'equitable' costs = for these=20 behaviors,
   or a way to make the system = forwarding behavior for these two load is somehow=20 'equitable'?
 
-----Original Message-----
From: = conex-bounces@ietf.org=20 [mailto:conex-bounces@ietf.org]On Behalf Of Toby=20 Moncaster
Sent: Thursday, February 24, 2011 1:36 = PM
To:=20 conex@ietf.org
Subject: [conex] Discussion of new Use Cases = pt=20 1

"Inequity of Heavy versus Light Users" use=20 case

 

It was agreed that the "Inequity" use case = from=20 draft-mcdysan-conex-other-usecases should be included in the WG = Concepts and=20 Use Cases draft. As mentioned in my earlier email, the hope is to = trigger a=20 discussion round the issues raised and to come to a consensus on what = actually=20 needs to appear in the revised draft.

 

From the discussion at Beijing it is apparent = that the=20 key aspect for defining heavy and light users here is timescales. The = worry=20 people have is that 20% of users are taking 80% of capacity, often = without=20 paying any extra for doing so. Quoting from Dave McDysan's=20 draft:

 

   During non-peak periods, the = resources of a=20 service or content

   provider are underutilized and = the marginal=20 cost of capacity is

   small.

 

   The access network is provisioned = and=20 traffic engineered for peak

   capacity of all users, and when = congested,=20 heavy users create 16

   times the congestion of small=20 users.

 

   However, during peak use periods, = a heavy=20 user may send at near the

   bandwidth tier while light users = may send=20 intermittently. There is a

   need for a means for service = providers to=20 equitably assign costs to

   heavy versus light users. For = example, the=20 light users may pay less

   if they were charged by volume, = as=20 described in another use case.

 

The proposal in the draft was to introduce a = "congestion=20 measure of burstiness (e.g., ratio of peak rate to average rate over a = longer=20 interval than the tiered bandwidth shaper or policer)". The assertion = is that=20 this measure of burstiness would allow heavy users to be identified = and hence=20 free up capacity for the lighter users.

 

So there are three questions for discussion:=20

 

1) is there a need for a new "congestion = measure of=20 burstiness" that would tag users as "heavy" or "light" over long=20 timescales?

 

2) how would the system be expected to react = differently=20 to heavy and light users?

 

3) can the same effect be achieved using = current=20 measures of congestion and current policing mechanisms?

 

There is also some question as to whether this = is the=20 best title for this use case. At its heart the use case is really = concerned=20 with timescales and so it might be better to include a section on = timescales=20 in the draft.

 

Toby

 

 

------_=_NextPart_001_01CBD46D.897FA0C4-- From john@jlc.net Thu Feb 24 14:10:43 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549CE3A6826 for ; Thu, 24 Feb 2011 14:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.713 X-Spam-Level: X-Spam-Status: No, score=-106.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knoU2s9kDQ1E for ; Thu, 24 Feb 2011 14:10:38 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 36ED23A683F for ; Thu, 24 Feb 2011 14:10:38 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id A130433C28; Thu, 24 Feb 2011 17:11:27 -0500 (EST) Date: Thu, 24 Feb 2011 17:11:27 -0500 From: John Leslie To: STUART VENTERS Message-ID: <20110224221127.GE7663@verdi> References: <006001cbd45a$0995aba0$1cc102e0$@com> <8F242B230AD6474C8E7815DE0B4982D7179FB91B@EXV1.corp.adtran.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB91B@EXV1.corp.adtran.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 24 Feb 2011 22:10:43 -0000 STUART VENTERS wrote: > > Let me make sure I understand this use case and it's desired outcome: > > Consider 2 users A, and B. > A sends at a low rate all the time. > B sends only a congestion causing bunch during busy times. > A sends many more bytes per month than B > > Which is the 'heavy' user (I think B)? I don't think we should assume that... > Are we looking for a way for service providers to determine 'equitable' > costs for these behaviors, or a way to make the system forwarding > behavior for these two load is somehow 'equitable'? To some degree, Dave has to speak for himself, but IMHO this issue is about being able (under ConEx) to better inform a provider's decision. I'm nearly positive Dave doesn't mean for us to argue what balance between these two is "equitable". At first blush, it would seem "B" should "expect" congestion losses, while "A" might not. Current non-ConEx methods tend to punish "A" more than "B"; and I do suspect Dave is suggesting a different balance might be appropriate. Nonetheless, IMHO "A" should expect congestion losses to increase during periods of heavy use -- unless s/he buys better-than the vanilla best-effort service. -- John Leslie From swmike@swm.pp.se Thu Feb 24 16:41:10 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDE73A68C0 for ; Thu, 24 Feb 2011 16:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9yrA2yrLYWX for ; Thu, 24 Feb 2011 16:41:10 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id DB7973A68C6 for ; Thu, 24 Feb 2011 16:41:09 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CB1049E; Fri, 25 Feb 2011 01:41:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C77DB9C; Fri, 25 Feb 2011 01:41:57 +0100 (CET) Date: Fri, 25 Feb 2011 01:41:57 +0100 (CET) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <006001cbd45a$0995aba0$1cc102e0$@com> Message-ID: References: <006001cbd45a$0995aba0$1cc102e0$@com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 00:41:10 -0000 On Thu, 24 Feb 2011, Toby Moncaster wrote: > There is also some question as to whether this is the best title for > this use case. At its heart the use case is really concerned with > timescales and so it might be better to include a section on timescales > in the draft. My impression is that often the 80/20 rule is over long timescales, including that they use a lot when marginal cost is low (because no congestion occured at that time). Wouldn't it just make sense to try to achieve equal amount of bandwidth access when congestion occurs, instead of trying to penalise people who used a lot of bandwidth before congestion occured? This would avoid the problem of having to identify "heavy users" over time but instead just identify them right now? -- Mikael Abrahamsson email: swmike@swm.pp.se From cait@asomi.com Thu Feb 24 16:47:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9473A68AE for ; Thu, 24 Feb 2011 16:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg6orNI+nXlk for ; Thu, 24 Feb 2011 16:47:20 -0800 (PST) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.39]) by core3.amsl.com (Postfix) with ESMTP id 4DBA53A68C0 for ; Thu, 24 Feb 2011 16:47:20 -0800 (PST) Received: (qmail 22939 invoked from network); 25 Feb 2011 00:48:11 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 25 Feb 2011 00:48:11 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: cait@asomi.com (speakeasy) In-Reply-To: <20110224221127.GE7663@verdi> Date: Thu, 24 Feb 2011 16:48:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006001cbd45a$0995aba0$1cc102e0$@com> <8F242B230AD6474C8E7815DE0B4982D7179FB91B@EXV1.corp.adtran.com> <20110224221127.GE7663@verdi> To: John Leslie X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 00:47:21 -0000 On Feb 24, 2011, at 2:11 PM, John Leslie wrote: > STUART VENTERS wrote: >>=20 >> Let me make sure I understand this use case and it's desired outcome: >>=20 >> Consider 2 users A, and B. >> A sends at a low rate all the time. >> B sends only a congestion causing bunch during busy times. >> A sends many more bytes per month than B >>=20 >> Which is the 'heavy' user (I think B)? >=20 > I don't think we should assume that... >=20 >> Are we looking for a way for service providers to determine = 'equitable' >> costs for these behaviors, or a way to make the system forwarding >> behavior for these two load is somehow 'equitable'? >=20 > To some degree, Dave has to speak for himself, but IMHO this issue = is > about being able (under ConEx) to better inform a provider's decision. > I'm nearly positive Dave doesn't mean for us to argue what balance = between > these two is "equitable". >=20 > At first blush, it would seem "B" should "expect" congestion losses, > while "A" might not. Current non-ConEx methods tend to punish "A" more > than "B"; and I do suspect Dave is suggesting a different balance = might > be appropriate. >=20 > Nonetheless, IMHO "A" should expect congestion losses to increase > during periods of heavy use -- unless s/he buys better-than the = vanilla > best-effort service. >=20 Add a 3rd user, C: C sends all the time, but has perfectly implemented a pre-standard = LEDBAT-style algorithm such that C sends *lots* of data when the network is idle = and next to none when the network is busy. Is C a heavier user than A, or B? To replay some discussions from RE-ECN, the congestion cost to the = network is a function of how deep in the queue a packet lands. The pricing strategies may = vary, but I find it very difficult to justify a conclusion that a packet low on the queue "costs = more" than one higher on the queue. The problem with measuring total bandwidth versus peak is that you would = actually penalize a flow for avoiding congestion successfully. That would certainly be = counter-productive. From stuart.venters@adtran.com Thu Feb 24 18:04:35 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E10A3A679C for ; Thu, 24 Feb 2011 18:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjRn+C5tBx+m for ; Thu, 24 Feb 2011 18:04:34 -0800 (PST) Received: from p02c12o142.mxlogic.net (p02c12o142.mxlogic.net [208.65.145.75]) by core3.amsl.com (Postfix) with ESMTP id 024FB3A6833 for ; Thu, 24 Feb 2011 18:04:33 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO p02c12o142.mxlogic.net) by p02c12o142.mxlogic.net(mxl_mta-6.9.0-1) with ESMTP id 56e076d4.2aaac5401940.24740.00-543.53333.p02c12o142.mxlogic.net (envelope-from ); Thu, 24 Feb 2011 19:05:25 -0700 (MST) X-MXL-Hash: 4d670e65776f8ff5-fb4b3922c64cf33996e0b6402fdc5ddacd274a59 Received: from unknown [76.164.174.82] by p02c12o142.mxlogic.net(mxl_mta-6.9.0-1) with SMTP id 35e076d4.0.24691.00-336.53246.p02c12o142.mxlogic.net (envelope-from ); Thu, 24 Feb 2011 19:05:15 -0700 (MST) X-MXL-Hash: 4d670e5b69c4e533-2ce110da1a8cb54b3ee3059e7a4a76c31a2b3707 Received: from corp-exfr1.corp.adtran.com (172.23.101.21) by ex-hc3.corp.adtran.com (172.22.50.73) with Microsoft SMTP Server id 14.1.270.1; Thu, 24 Feb 2011 20:05:06 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr1.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Feb 2011 20:05:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD490.6BD01DF8" Date: Thu, 24 Feb 2011 20:05:05 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D719E65545@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvUha7eTYekPzwbS1+O3RCtTpbfmQACVW8Y References: <006001cbd45a$0995aba0$1cc102e0$@com> <8F242B230AD6474C8E7815DE0B4982D7179FB91B@EXV1.corp.adtran.com> <20110224221127.GE7663@verdi> From: STUART VENTERS To: speakeasy , John Leslie X-OriginalArrivalTime: 25 Feb 2011 02:05:06.0750 (UTC) FILETIME=[6C4C25E0:01CBD490] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] X-AnalysisOut: [v=1.0 c=1 a=G9T4uwCCN8UA:10 a=BLceEmwcHowA:10 a=J+LXdEUA8t] X-AnalysisOut: [8MtBPt16/Qbg==:17 a=qT0HhdkYAAAA:8 a=48vgC7mUAAAA:8 a=eJNr] X-AnalysisOut: [pioGAAAA:8 a=qiNDaGR3v7U0KgPHu8gA:9 a=QDHV_g3VV_WLIe0ohGkA] X-AnalysisOut: [:7 a=uiqFZldkUbzqBohp4OFIZ11R5LUA:4 a=wPNLvfGTeEIA:10 a=CL] X-AnalysisOut: [erPekyddsA:10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a=ebNIGf] X-AnalysisOut: [2GwLRJ0eB-IF0A:7 a=2HroJiOQidCLjii8qhcZBpJg8sYA:4] Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 02:04:35 -0000 ------_=_NextPart_001_01CBD490.6BD01DF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> or C C is an interesting user he is both really behaved in terms of causing = little congestion and also probably getting more bytes per month that = even user A. Perhaps the right question is not to pick the heavy users, = but rather the heavy congestion users. >>the congestion cost to the network is a function of how deep in the = queue a packet lands. I guess this is the same as the time the packet spends in queues in = the network. On a related issue: So if there is few fields in the IPV6 header that are available in the = forwarding path, how about the TTL field. Maybe decrement is extra counts for extra time in a queue. -----Original Message----- From: speakeasy [mailto:cait@asomi.com] Sent: Thu 2/24/2011 6:48 PM To: John Leslie Cc: STUART VENTERS; conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 =20 On Feb 24, 2011, at 2:11 PM, John Leslie wrote: > STUART VENTERS wrote: >>=20 >> Let me make sure I understand this use case and it's desired outcome: >>=20 >> Consider 2 users A, and B. >> A sends at a low rate all the time. >> B sends only a congestion causing bunch during busy times. >> A sends many more bytes per month than B >>=20 >> Which is the 'heavy' user (I think B)? >=20 > I don't think we should assume that... >=20 >> Are we looking for a way for service providers to determine = 'equitable' >> costs for these behaviors, or a way to make the system forwarding >> behavior for these two load is somehow 'equitable'? >=20 > To some degree, Dave has to speak for himself, but IMHO this issue = is > about being able (under ConEx) to better inform a provider's decision. > I'm nearly positive Dave doesn't mean for us to argue what balance = between > these two is "equitable". >=20 > At first blush, it would seem "B" should "expect" congestion losses, > while "A" might not. Current non-ConEx methods tend to punish "A" more > than "B"; and I do suspect Dave is suggesting a different balance = might > be appropriate. >=20 > Nonetheless, IMHO "A" should expect congestion losses to increase > during periods of heavy use -- unless s/he buys better-than the = vanilla > best-effort service. >=20 Add a 3rd user, C: C sends all the time, but has perfectly implemented a pre-standard = LEDBAT-style algorithm such that C sends *lots* of data when the network is idle = and next to none when the network is busy. Is C a heavier user than A, or B? To replay some discussions from RE-ECN, the congestion cost to the = network is a function of how deep in the queue a packet lands. The pricing strategies may = vary, but I find it very difficult to justify a conclusion that a packet low on the queue "costs = more" than one higher on the queue. The problem with measuring total bandwidth versus peak is that you would = actually penalize a flow for avoiding congestion successfully. That would certainly be = counter-productive. ------_=_NextPart_001_01CBD490.6BD01DF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [conex] Discussion of new Use Cases pt 1

>> or C
  C is an interesting user he is both really behaved in terms of = causing little congestion and also probably getting more bytes per month = that even user A.  Perhaps the right question is not to pick the = heavy users, but rather the heavy congestion users.

>>the congestion cost to the network is a function of how deep in = the queue a packet lands.
  I guess this is the same as the time the packet spends in queues = in the network.


On a related issue:
So if there is few fields in the IPV6 header that are available in the = forwarding path, how about the TTL field.
   Maybe decrement is extra counts for extra time in a = queue.




-----Original Message-----
From: speakeasy [mailto:cait@asomi.com]
Sent: Thu 2/24/2011 6:48 PM
To: John Leslie
Cc: STUART VENTERS; conex@ietf.org
Subject: Re: [conex] Discussion of new Use Cases pt 1


On Feb 24, 2011, at 2:11 PM, John Leslie wrote:

> STUART VENTERS <stuart.venters@adtran.com> wrote:
>>
>> Let me make sure I understand this use case and it's desired = outcome:
>>
>> Consider 2 users A, and B.
>>   A sends at a low rate all the time.
>>   B sends only a congestion causing bunch during busy = times.
>>   A sends many more bytes per month than B
>>
>> Which is the 'heavy' user (I think B)?
>
>   I don't think we should assume that...
>
>> Are we looking for a way for service providers to determine = 'equitable'
>> costs for these behaviors, or a way to make the system = forwarding
>> behavior for these two load is somehow 'equitable'?
>
>   To some degree, Dave has to speak for himself, but IMHO = this issue is
> about being able (under ConEx) to better inform a provider's = decision.
> I'm nearly positive Dave doesn't mean for us to argue what balance = between
> these two is "equitable".
>
>   At first blush, it would seem "B" should = "expect" congestion losses,
> while "A" might not. Current non-ConEx methods tend to = punish "A" more
> than "B"; and I do suspect Dave is suggesting a different = balance might
> be appropriate.
>
>   Nonetheless, IMHO "A" should expect = congestion losses to increase
> during periods of heavy use -- unless s/he buys better-than the = vanilla
> best-effort service.
>

Add a 3rd user, C:

   C sends all the time, but has perfectly implemented a = pre-standard LEDBAT-style
   algorithm such that C sends *lots* of data when the network = is idle and next to none
   when the network is busy.

Is C a heavier user than A, or B?

To replay some discussions from RE-ECN, the congestion cost to the = network is a function
of how deep in the queue a packet lands. The pricing strategies may = vary, but I find it very
difficult to justify a conclusion that a packet low on the queue = "costs more" than one higher
on the queue.

The problem with measuring total bandwidth versus peak is that you would = actually penalize
a flow for avoiding congestion successfully. That would certainly be = counter-productive.

------_=_NextPart_001_01CBD490.6BD01DF8-- From swmike@swm.pp.se Thu Feb 24 18:05:32 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6543A68B0 for ; Thu, 24 Feb 2011 18:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVBfF8YjyglO for ; Thu, 24 Feb 2011 18:05:32 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id C5F963A679C for ; Thu, 24 Feb 2011 18:05:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B91DD9E; Fri, 25 Feb 2011 03:06:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B89DA9C for ; Fri, 25 Feb 2011 03:06:21 +0100 (CET) Date: Fri, 25 Feb 2011 03:06:21 +0100 (CET) From: Mikael Abrahamsson To: conex In-Reply-To: <1298595193-sup-8334@moonloop.syshex.com> Message-ID: References: <006001cbd45a$0995aba0$1cc102e0$@com> <1298595193-sup-8334@moonloop.syshex.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-761166557-1298599581=:11974" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 02:05:32 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-761166557-1298599581=:11974 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 25 Feb 2011, João Taveira Araújo wrote: > This can be done with variants of fair queuing, but it doesn't provide > the incentives for bulk traffic to be shifted to avoid congestion. Why > throttle now if you'll both suffer now and not reap any benefits later? > There is an overview of the design space in section 3 of > http://bobbriscoe.net/projects/refb/polfree_rearch08.pdf . If each user gets equal share of the traffic then the incentive to mark bulk traffic as such is that that perticular user will have a much better interactive traffic experience when that person uses both at the same time at time of congestion. Also, if there is a congestion usage cap, the bulk marked traffic wouldn't be counted as part of that cap, I guess? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-761166557-1298599581=:11974-- From lists@syshex.com Thu Feb 24 18:37:55 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740E13A68F8 for ; Thu, 24 Feb 2011 18:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XyIeV0I0-zj for ; Thu, 24 Feb 2011 18:37:54 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 77AF73A68F7 for ; Thu, 24 Feb 2011 18:37:54 -0800 (PST) Received: by pvd12 with SMTP id 12so233046pvd.31 for ; Thu, 24 Feb 2011 18:38:45 -0800 (PST) Received: by 10.142.149.6 with SMTP id w6mr612543wfd.437.1298601525347; Thu, 24 Feb 2011 18:38:45 -0800 (PST) Received: from localhost ([192.55.118.186]) by mx.google.com with ESMTPS id n4sm255012wfl.14.2011.02.24.18.38.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Feb 2011 18:38:44 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?Jo=C3=A3o_Taveira_Ara=C3=BAjo?= To: Mikael Abrahamsson In-reply-to: References: <006001cbd45a$0995aba0$1cc102e0$@com> <1298595193-sup-8334@moonloop.syshex.com> Date: Fri, 25 Feb 2011 11:38:40 +0900 Message-Id: <1298600085-sup-8327@moonloop.syshex.com> User-Agent: Sup/0.11 Content-Transfer-Encoding: 8bit Cc: conex Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 02:37:55 -0000 Excerpts from Mikael Abrahamsson's message of Fri Feb 25 11:06:21 +0900 2011: > On Fri, 25 Feb 2011, João Taveira Araújo wrote: > > > This can be done with variants of fair queuing, but it doesn't provide > > the incentives for bulk traffic to be shifted to avoid congestion. Why > > throttle now if you'll both suffer now and not reap any benefits later? > > There is an overview of the design space in section 3 of > > http://bobbriscoe.net/projects/refb/polfree_rearch08.pdf . > > If each user gets equal share of the traffic then the incentive to mark > bulk traffic as such is that that perticular user will have a much better > interactive traffic experience when that person uses both at the same > time at time of congestion. > > Also, if there is a congestion usage cap, the bulk marked traffic wouldn't > be counted as part of that cap, I guess? > I was assuming you would just mark packets experiencing congestion rather than use LE marked traffic. In that case the rate at which lower-than-best-effort traffic experiences congestion should be lower simply because it is more conservative and backs off. Over time the amount of congestion caused might be the same as competing interactive traffic, but the rates at which congestion volume is consumed is different. In theory this allows for a whole range of behaviour rather than trying to classify traffic into specific categories, which is my main concern with simply marking traffic as "bulk". That just fragments what we have now in two. And what we have now is the Orwellian "all types traffic are equal, but some types of traffic are more equal than others". J From dave.mcdysan@verizon.com Fri Feb 25 06:17:19 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5190A3A69D0 for ; Fri, 25 Feb 2011 06:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJJPWSAiXCE3 for ; Fri, 25 Feb 2011 06:17:18 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id C872E3A68D4 for ; Fri, 25 Feb 2011 06:17:09 -0800 (PST) Received: from fldsmtpi02.verizon.com ([166.68.71.144]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p1PEHl2X011831 for ; Fri, 25 Feb 2011 09:18:02 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="1205092" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 25 Feb 2011 14:17:47 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Fri, 25 Feb 2011 09:17:47 -0500 To: John Leslie , STUART VENTERS Date: Fri, 25 Feb 2011 09:17:44 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvU9sahP3jlHjAWSM+6J9cxW37FHA== Message-ID: In-Reply-To: <20110224221127.GE7663@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 14:17:19 -0000 There are several ideas being combined here and it may be best to separate them and agree on some more precise terminology. First, assume that the users are in the same QoS class and that the incentive is the"flat rate" or "bandwidth tier" pricing. That is, there is no long term usage tier pricing in place. In many networks a non work conserving scheduler (e.g., a shaper) implements the peak rate over an interval O(100 ms). Thus, the "bandwidth tier" incentive is that a user pays more if he/she wants more peak rate bandwidth. If the user sends at more than the purchased peak rate and there is no congestion at a shared resource, then other users are not impacted, and in a sense this user creates "self-congestion." The current conex WG use case draft focuses on the case when congestion occurs at a shared resource, which causes "inter-user-congestion." The proposed measure from the text that Toby sent from my draft for this use case is that of burstiness (I.e., peak/average) where the incentive peak is the"flat rate" or "bandwidth tier" purchased. Typically, statistical multiplexing is assumed since many of the user traffic patterns exhibit high burstiness and network share resources are not provisioned at potential congestion points such that all users can send at the peak rate. If the shared resource points are provisioned such that all users can send at the peak rate (I.e., their bandwidth tier) then only "self-congestion" can occur and "inter-user-congestion" cannot occur. So, now consider two (classes of) users A and B during a time period where congestion of a shared resource is occurring causing "inter-user-congestion": Class A sends at an average rate much less than the peak rate of his/her bandwidth tier (i.e., is VERY bursty and statistically multiplexable) Class B sends at an average rate that is near the peak rate of his/her bandwidth tier for a time period much longer than the shaper queue depth, potentially causing "self-congestion" as well (i.e., is NOT bursty and NOT statistically multiplexable) (Note that LEDBAT would avoid "self-congestion") For the cited example, if 20% of the class B users send 80% of the traffic during the (relatively long) interval during which the shared resource is congested, then class B is sending 16x the traffic as compared with the class A users. What typically happens today at the congested shared resource(s) is that user classes A and B will experience similar packet drop probabilities, and hence similar goodput (as contributed to by "inter-user-congestion") I agree with John "this issue is about being able (under ConEx) to better inform a provider's decision." I would add that this also could enable other forms of incentives (I.e., selective traffic management, and/or a another form of pricing) Let me illustrate by an example. If conex could send longer-term user burstiness to the congested shared resource, then a mechanism (to be described in the mechanism draft) at that point could drop more traffic from class B non-bursty users so that bandwidth tends to equalize between the two user classes Implement a bandwidth tier AND burst duration pricing scheme, with appropriate mechanisms to provide a burst duration longer than the shapers widely used today Thanks, Dave On 2/24/11 5:11 PM, "John Leslie" wrote: >STUART VENTERS wrote: >>=20 >> Let me make sure I understand this use case and it's desired outcome: >> =20 >> Consider 2 users A, and B. >> A sends at a low rate all the time. >> B sends only a congestion causing bunch during busy times. >> A sends many more bytes per month than B >> =20 >> Which is the 'heavy' user (I think B)? > > I don't think we should assume that... > >> Are we looking for a way for service providers to determine 'equitable' >> costs for these behaviors, or a way to make the system forwarding >> behavior for these two load is somehow 'equitable'? > > To some degree, Dave has to speak for himself, but IMHO this issue is >about being able (under ConEx) to better inform a provider's decision. >I'm nearly positive Dave doesn't mean for us to argue what balance between >these two is "equitable". > > At first blush, it would seem "B" should "expect" congestion losses, >while "A" might not. Current non-ConEx methods tend to punish "A" more >than "B"; and I do suspect Dave is suggesting a different balance might >be appropriate. > > Nonetheless, IMHO "A" should expect congestion losses to increase >during periods of heavy use -- unless s/he buys better-than the vanilla >best-effort service. > >-- >John Leslie >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Fri Feb 25 06:18:27 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6363A69D7 for ; Fri, 25 Feb 2011 06:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32sxq8H0a+EU for ; Fri, 25 Feb 2011 06:18:26 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id B70AF3A68D4 for ; Fri, 25 Feb 2011 06:18:21 -0800 (PST) Received: from fldsmtpi01.verizon.com ([166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p1PEJEe5013169 for ; Fri, 25 Feb 2011 09:19:14 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="1206958" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 25 Feb 2011 14:19:13 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Fri, 25 Feb 2011 09:19:13 -0500 To: Mikael Abrahamsson , Toby Moncaster Date: Fri, 25 Feb 2011 09:19:12 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvU9voVrzgTxD8aQgifuJ7FK6ek1g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 14:18:27 -0000 I agree that nne mechanism that could use the proposed burstiness measure is "to try to achieve equal amount of bandwidth access when congestion occurs" (at a shared resource). Dave On 2/24/11 7:41 PM, "Mikael Abrahamsson" wrote: >On Thu, 24 Feb 2011, Toby Moncaster wrote: > >> There is also some question as to whether this is the best title for >> this use case. At its heart the use case is really concerned with >> timescales and so it might be better to include a section on timescales >> in the draft. > >My impression is that often the 80/20 rule is over long timescales, >including that they use a lot when marginal cost is low (because no >congestion occured at that time). > >Wouldn't it just make sense to try to achieve equal amount of bandwidth >access when congestion occurs, instead of trying to penalise people who >used a lot of bandwidth before congestion occured? This would avoid the >problem of having to identify "heavy users" over time but instead just >identify them right now? > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Fri Feb 25 06:22:29 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7883A69CF for ; Fri, 25 Feb 2011 06:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkJkQaiqjR+z for ; Fri, 25 Feb 2011 06:22:28 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id A746F3A67EC for ; Fri, 25 Feb 2011 06:22:24 -0800 (PST) Received: from fldsmtpi03.verizon.com ([166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p1PENGtP015469 for ; Fri, 25 Feb 2011 09:23:17 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="1206034" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 25 Feb 2011 14:23:05 +0000 Received: from FHDP1CCMXCL02.us.one.verizon.com (166.68.240.32) by FHDP1LUMXC7HB04.us.one.verizon.com (166.68.59.191) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 25 Feb 2011 09:23:04 -0500 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1CCMXCL02.us.one.verizon.com ([166.68.240.32]) with mapi; Fri, 25 Feb 2011 09:23:05 -0500 To: speakeasy , John Leslie Date: Fri, 25 Feb 2011 09:23:01 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvU94PHOoScg+dQTi+iVr/u5ukfMQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 14:22:29 -0000 When the incentive is "flat rate" or "bandwidth tier" then uncongested periods are irrelevant. When usage tier pricing is in place, then this is another case which several WG members at the Beijing meeting commented that this case was out of scope. There has been no subsequent discussion on the list regarding this topic. A question on terminology: what does "total bandwidth" mean as used in the last sentence of your post? Thanks, Dave On 2/24/11 7:48 PM, "speakeasy" wrote: > >On Feb 24, 2011, at 2:11 PM, John Leslie wrote: > >> STUART VENTERS wrote: >>>=20 >>> Let me make sure I understand this use case and it's desired outcome: >>>=20 >>> Consider 2 users A, and B. >>> A sends at a low rate all the time. >>> B sends only a congestion causing bunch during busy times. >>> A sends many more bytes per month than B >>>=20 >>> Which is the 'heavy' user (I think B)? >>=20 >> I don't think we should assume that... >>=20 >>> Are we looking for a way for service providers to determine 'equitable' >>> costs for these behaviors, or a way to make the system forwarding >>> behavior for these two load is somehow 'equitable'? >>=20 >> To some degree, Dave has to speak for himself, but IMHO this issue is >> about being able (under ConEx) to better inform a provider's decision. >> I'm nearly positive Dave doesn't mean for us to argue what balance >>between >> these two is "equitable". >>=20 >> At first blush, it would seem "B" should "expect" congestion losses, >> while "A" might not. Current non-ConEx methods tend to punish "A" more >> than "B"; and I do suspect Dave is suggesting a different balance might >> be appropriate. >>=20 >> Nonetheless, IMHO "A" should expect congestion losses to increase >> during periods of heavy use -- unless s/he buys better-than the vanilla >> best-effort service. >>=20 > >Add a 3rd user, C: > > C sends all the time, but has perfectly implemented a pre-standard >LEDBAT-style > algorithm such that C sends *lots* of data when the network is idle >and next to none > when the network is busy. > >Is C a heavier user than A, or B? > >To replay some discussions from RE-ECN, the congestion cost to the >network is a function >of how deep in the queue a packet lands. The pricing strategies may vary, >but I find it very >difficult to justify a conclusion that a packet low on the queue "costs >more" than one higher >on the queue. > >The problem with measuring total bandwidth versus peak is that you would >actually penalize >a flow for avoiding congestion successfully. That would certainly be >counter-productive. > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Fri Feb 25 06:38:08 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF44D3A67EC for ; Fri, 25 Feb 2011 06:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1QpEUDQutjh for ; Fri, 25 Feb 2011 06:38:07 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 2E5CD3A687C for ; Fri, 25 Feb 2011 06:38:03 -0800 (PST) Received: from fldsmtpi01.verizon.com ([166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p1PEctrn026345 for ; Fri, 25 Feb 2011 09:38:55 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="1220685" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 25 Feb 2011 14:38:55 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Fri, 25 Feb 2011 09:38:54 -0500 To: =?iso-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= , Mikael Abrahamsson Date: Fri, 25 Feb 2011 09:38:52 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvU+boAaApgQJ+2SiWARC5GIB93nQ== Message-ID: In-Reply-To: <1298600085-sup-8327@moonloop.syshex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: conex Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 14:38:09 -0000 I think there are other use cases in this thread that we could consider: - Interaction between conex and different QoS classes (e.g., LE and Interactive (BE?) as reported by Conex (Not sure if the current use case draft covers this sufficiently) - Interaction between conex and Usage tier pricing (aka Usage caps) (As I posted earlier, as documented in the meeting minutes some WG members voiced belief in Beijing that this was out of WG scope -- appears there is some WG interest in this topic based upon the posts over the past day). - Time shifting of bulk traffic to non-congested intervals (I proposed this use case in my draft in Beijing, and there was WG interest but as documented in the meeting minutes WG members voiced belief in Beijing that this was out of WG scope. I was asked at the meeting to write more up about this in an individual draft and the WG might later decide to include it). In addition to the WG member verbal feedback documented in the Beijing meeting notes, it would be good to hear from the list regarding the types of use cases they would like to address. Thanks, Dave On 2/24/11 9:38 PM, "Jo=E3o Taveira Ara=FAjo" wrote: >Excerpts from Mikael Abrahamsson's message of Fri Feb 25 11:06:21 +0900 >2011: >> On Fri, 25 Feb 2011, Jo=E3o Taveira Ara=FAjo wrote: >>=20 >> > This can be done with variants of fair queuing, but it doesn't >>provide=20 >> > the incentives for bulk traffic to be shifted to avoid congestion. >>Why=20 >> > throttle now if you'll both suffer now and not reap any benefits >>later?=20 >> > There is an overview of the design space in section 3 of >> > http://bobbriscoe.net/projects/refb/polfree_rearch08.pdf . >>=20 >> If each user gets equal share of the traffic then the incentive to mark >> bulk traffic as such is that that perticular user will have a much >>better=20 >> interactive traffic experience when that person uses both at the same >> time at time of congestion. >> >> Also, if there is a congestion usage cap, the bulk marked traffic >>wouldn't=20 >> be counted as part of that cap, I guess? >>=20 > > >I was assuming you would just mark packets experiencing congestion rather >than use LE marked traffic. In that case the rate at which >lower-than-best-effort traffic experiences congestion should be lower >simply because it is more conservative and backs off. Over time the >amount of congestion caused might be the same as competing interactive >traffic, but the rates at which congestion volume is consumed is >different. > >In theory this allows for a whole range of behaviour rather than trying >to classify traffic into specific categories, which is my main concern >with simply marking traffic as "bulk". That just fragments what we have >now in two. And what we have now is the Orwellian "all types traffic are >equal, but some types of traffic are more equal than others". > >J >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Fri Feb 25 06:59:00 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D24C3A69DD for ; Fri, 25 Feb 2011 06:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTwkauXgUPHL for ; Fri, 25 Feb 2011 06:58:59 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id D5CA13A69C3 for ; Fri, 25 Feb 2011 06:58:58 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 97C669F; Fri, 25 Feb 2011 15:59:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9611E9C; Fri, 25 Feb 2011 15:59:49 +0100 (CET) Date: Fri, 25 Feb 2011 15:59:49 +0100 (CET) From: Mikael Abrahamsson To: "Mcdysan, David E" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 25 Feb 2011 14:59:00 -0000 On Fri, 25 Feb 2011, Mcdysan, David E wrote: > I think there are other use cases in this thread that we could consider: > - Interaction between conex and different QoS classes (e.g., LE and > Interactive (BE?) as reported by Conex (Not sure if the current use case > draft covers this sufficiently) > - Interaction between conex and Usage tier pricing (aka Usage caps) (As I > posted earlier, as documented in the meeting minutes some WG members > voiced belief in Beijing that this was out of WG scope -- appears there is > some WG interest in this topic based upon the posts over the past day). > - Time shifting of bulk traffic to non-congested intervals (I proposed > this use case in my draft in Beijing, and there was WG interest but as > documented in the meeting minutes WG members voiced belief in Beijing that > this was out of WG scope. I was asked at the meeting to write more up > about this in an individual draft and the WG might later decide to include > it). Personally I currently see the following problems: Users cause self-congestion on their access link and AQM doesn't exist. There should be recommendations on what devices should do to provide a good end user experience (less-than-be for background transfers, have separate queues for small packets (might be easy way to catch SYN/ACK/VOIP), ECN/WRED behaviour and other things that can be agreed upon). This ties into the "buffer bloat" arguments that are going around. I believe we in the ISP industry as a whole has failed to provide adequate handling of queues for user traffic to create a good user experience under self-congestion. Same as above but for the shared links. My thinking is that Less-than-BE would automatically be shifted away from peak hour if shared congestion occurs since it's less prioritized than BE, so it'll be painfully slow when other shared congestion occurs. So we should look closely at how to provide the best end-user experience under shared congestion, without starving out some users completely. I believe the scheme should follow the KISS principle as much as can be done, the more advanced the proposal is, the less likely is that it'll be deployed in any timely manner. Remember ECN still after 10 years isn't widely deployed in ISP infrastructure. It's most of the time not enabled on end-systems either... -- Mikael Abrahamsson email: swmike@swm.pp.se From acooper@cdt.org Sat Feb 26 04:20:30 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A212F3A6800 for ; Sat, 26 Feb 2011 04:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3bKgBpLOPVP for ; Sat, 26 Feb 2011 04:20:29 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 40AE23A67B6 for ; Sat, 26 Feb 2011 04:20:29 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 26 Feb 2011 07:21:18 -0500 Message-Id: From: Alissa Cooper To: "Mcdysan, David E" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 26 Feb 2011 12:21:16 +0000 References: X-Mailer: Apple Mail (2.936) Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:20:30 -0000 Hi Dave, Couple of questions inline... On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: > The proposed measure from the text that Toby sent from my draft for > this > use case is that of burstiness (I.e., peak/average) where the > incentive > peak is the"flat rate" or "bandwidth tier" purchased. > ... > > Let me illustrate by an example. If conex could send longer-term user > burstiness to the congested shared resource, then a mechanism (to be > described in the mechanism draft) at that point could > drop more traffic from class B non-bursty users so that bandwidth > tends > to equalize between the two user classes > Implement a bandwidth tier AND burst duration pricing scheme, with > appropriate mechanisms to provide a burst duration longer than the > shapers > widely used today > It seems to me that there are two different approaches being taken to what is or is not in scope for both the use cases and the mechanism definition: Approach #1: a. Assume that the CONEX mechanism will be used exclusively to signal the amount of congestion encountered by previous packets on the same flow b. Document the different uses to which that signal could be put (traffic management, incentivizing scavenger services, etc.) in the use cases draft c. Document how the signal is set in the mechanism draft Approach #2: a. Assume that the metric that CONEX will signal is open for discussion, or that the mechanism may signal multiple different metrics b. Document use cases for a variety of different potential metrics in the use cases draft (congestion encountered previously on same flow, long-term user burstiness as you describe above, possibly others) c. Document how network nodes could respond to CONEX signals to effectuate particular outcomes (dropping more traffic from non-bursty users as you describe above) It seems as though you are taking approach #2 whereas others may be taking approach #1, and these two approaches probably need to be reconciled. I don't see how the same mechanism can signal both congestion previously experienced on the path and peak/average sending rate (although I'm happy for you or someone else to explain how it can be done). If it can't be done, then it seems like we are talking about signaling two different metrics. If we are focused on a single metric, then I think we need to document use cases for that metric. If there are multiple metrics, we should be clear about which use cases make use of which metric. And in either case, I thought the point of the mechanism draft was to explain how the chosen metric is measured so that it can be encoded at the IP layer. Alissa > > Thanks, > > Dave > > > On 2/24/11 5:11 PM, "John Leslie" wrote: > >> STUART VENTERS wrote: >>> >>> Let me make sure I understand this use case and it's desired >>> outcome: >>> >>> Consider 2 users A, and B. >>> A sends at a low rate all the time. >>> B sends only a congestion causing bunch during busy times. >>> A sends many more bytes per month than B >>> >>> Which is the 'heavy' user (I think B)? >> >> I don't think we should assume that... >> >>> Are we looking for a way for service providers to determine >>> 'equitable' >>> costs for these behaviors, or a way to make the system forwarding >>> behavior for these two load is somehow 'equitable'? >> >> To some degree, Dave has to speak for himself, but IMHO this issue >> is >> about being able (under ConEx) to better inform a provider's >> decision. >> I'm nearly positive Dave doesn't mean for us to argue what balance >> between >> these two is "equitable". >> >> At first blush, it would seem "B" should "expect" congestion losses, >> while "A" might not. Current non-ConEx methods tend to punish "A" >> more >> than "B"; and I do suspect Dave is suggesting a different balance >> might >> be appropriate. >> >> Nonetheless, IMHO "A" should expect congestion losses to increase >> during periods of heavy use -- unless s/he buys better-than the >> vanilla >> best-effort service. >> >> -- >> John Leslie >> _______________________________________________ >> 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 > From toby@moncaster.com Sat Feb 26 04:49:42 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1B73A683C for ; Sat, 26 Feb 2011 04:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtzdbUXBIZ3Z for ; Sat, 26 Feb 2011 04:49:41 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 3EA5B3A6800 for ; Sat, 26 Feb 2011 04:49:40 -0800 (PST) Received: from TobysHP (host81-158-50-164.range81-158.btcentralplus.com [81.158.50.164]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M5Ijf-1QEojW3lDL-00zZV9; Sat, 26 Feb 2011 13:50:10 +0100 From: "Toby Moncaster" To: "'Alissa Cooper'" , "'Mcdysan, David E'" References: In-Reply-To: Date: Sat, 26 Feb 2011 12:50:11 -0000 Message-ID: <001201cbd5b3$b5114020$1f33c060$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcvVr7Jy0MzGnUZ0ToaBtJ/DmlLWbwAAnWRA Content-Language: en-gb X-Provags-ID: V02:K0:DhXJwJEm/AH6JHjSdAVJ+C7ZyvMDrXo8KSSBgEoE8GN G8atHbwGFY5hZOvkhi8+Akv/KWodwrgCDTKXcAdWlw5GTX1zlH RbKJ8+/f4Y2hCCke/zm6z9ddNfOjt37RwsSP+D5S5vSZEiufKC E9nIHCkqEQ28cI0cmsr8J6AtRDDIjBrr2pFMOQFdyPQjSLUlLr 8vNBZAY3HzhxVq/BQ5i2+0YzuyflRqKZDR5t72A02I= Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:49:43 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Alissa Cooper > Sent: 26 February 2011 12:21 > To: Mcdysan, David E > Cc: conex@ietf.org > Subject: Re: [conex] Discussion of new Use Cases pt 1 > > Hi Dave, > > Couple of questions inline... > > On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: > > The proposed measure from the text that Toby sent from my draft for > > this > > use case is that of burstiness (I.e., peak/average) where the > > incentive > > peak is the"flat rate" or "bandwidth tier" purchased. > > ... > > > > Let me illustrate by an example. If conex could send longer-term user > > burstiness to the congested shared resource, then a mechanism (to be > > described in the mechanism draft) at that point could > > drop more traffic from class B non-bursty users so that bandwidth > > tends > > to equalize between the two user classes > > Implement a bandwidth tier AND burst duration pricing scheme, with > > appropriate mechanisms to provide a burst duration longer than the > > shapers > > widely used today > > > > It seems to me that there are two different approaches being taken to > what is or is not in scope for both the use cases and the mechanism > definition: > > Approach #1: > a. Assume that the CONEX mechanism will be used exclusively to signal > the amount of congestion encountered by previous packets on the same > flow > b. Document the different uses to which that signal could be put > (traffic management, incentivizing scavenger services, etc.) in the > use cases draft > c. Document how the signal is set in the mechanism draft This is certainly the approach in draft-ietf-conex-concepts-uses and the co-authors of that document assumed this was what the charter was looking for. > > Approach #2: > a. Assume that the metric that CONEX will signal is open for > discussion, or that the mechanism may signal multiple different metrics > b. Document use cases for a variety of different potential metrics in > the use cases draft (congestion encountered previously on same flow, > long-term user burstiness as you describe above, possibly others) > c. Document how network nodes could respond to CONEX signals to > effectuate particular outcomes (dropping more traffic from non-bursty > users as you describe above) The potential problem with this approach is that there is no end to the possible metrics that we could explore. In theory we are meant to be submitting the Use Cases document by March this year! So we do need to be sensible about what is in and out of scope. > > It seems as though you are taking approach #2 whereas others may be > taking approach #1, and these two approaches probably need to be > reconciled. I don't see how the same mechanism can signal both > congestion previously experienced on the path and peak/average sending > rate (although I'm happy for you or someone else to explain how it can > be done). If it can't be done, then it seems like we are talking about > signaling two different metrics. I certainly favour approach 1, and this seems to better match with our charter. On the other hand there is potential for looking at broader definitions of congestion within the use cases document. One of the big issues facing the WG is defining congestion in a sensible fashion. I agree that Dave's peak/average rate signal doesn't seem to fit into the same sort of signalling framework. For one thing Dave seems to just imply this would be a binary state. However I think it may be possible to derive something that gives the same information as Dave is looking for without needing an additional explicit signal. > > If we are focused on a single metric, then I think we need to document > use cases for that metric. If there are multiple metrics, we should be > clear about which use cases make use of which metric. And in either > case, I thought the point of the mechanism draft was to explain how > the chosen metric is measured so that it can be encoded at the IP > layer. I favour concentrating on a single metric relating as closely as possible to "real" congestion. But Dave does have a very valid point - for whatever reason, many ISPs use a shaper to rate limit traffic to/from their customers. I would argue that at peak times this is probably not the limiting factor, but off-peak it will be the biggest source of apparent loss/congestion. One interesting thought experiment - what if, instead of a shaper, the ISP introduces a congestion marking system. Then it can rate limit traffic by marking it before the traffic needs to be disrupted. The only problem then is how to deal with non-responsive traffic. Toby > > Alissa > > > > > Thanks, > > > > Dave > > > > > > On 2/24/11 5:11 PM, "John Leslie" wrote: > > > >> STUART VENTERS wrote: > >>> > >>> Let me make sure I understand this use case and it's desired > >>> outcome: > >>> > >>> Consider 2 users A, and B. > >>> A sends at a low rate all the time. > >>> B sends only a congestion causing bunch during busy times. > >>> A sends many more bytes per month than B > >>> > >>> Which is the 'heavy' user (I think B)? > >> > >> I don't think we should assume that... > >> > >>> Are we looking for a way for service providers to determine > >>> 'equitable' > >>> costs for these behaviors, or a way to make the system forwarding > >>> behavior for these two load is somehow 'equitable'? > >> > >> To some degree, Dave has to speak for himself, but IMHO this issue > >> is > >> about being able (under ConEx) to better inform a provider's > >> decision. > >> I'm nearly positive Dave doesn't mean for us to argue what balance > >> between > >> these two is "equitable". > >> > >> At first blush, it would seem "B" should "expect" congestion > losses, > >> while "A" might not. Current non-ConEx methods tend to punish "A" > >> more > >> than "B"; and I do suspect Dave is suggesting a different balance > >> might > >> be appropriate. > >> > >> Nonetheless, IMHO "A" should expect congestion losses to increase > >> during periods of heavy use -- unless s/he buys better-than the > >> vanilla > >> best-effort service. > >> > >> -- > >> John Leslie > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Sat Feb 26 06:55:23 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD113A6944 for ; Sat, 26 Feb 2011 06:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.698 X-Spam-Level: X-Spam-Status: No, score=-106.698 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LSlMHGDnJJC for ; Sat, 26 Feb 2011 06:55:21 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 6C1D23A68D4 for ; Sat, 26 Feb 2011 06:55:21 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8FDE233C23; Sat, 26 Feb 2011 09:56:16 -0500 (EST) Date: Sat, 26 Feb 2011 09:56:16 -0500 From: John Leslie To: Toby Moncaster Message-ID: <20110226145616.GH7663@verdi> References: <001201cbd5b3$b5114020$1f33c060$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201cbd5b3$b5114020$1f33c060$@com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 14:55:23 -0000 Toby Moncaster wrote: > To: "'Alissa Cooper'" , > >> It seems to me that there are two different approaches being taken to >> what is or is not in scope for both the use cases and the mechanism >> definition: >> >> Approach #1: >> a. Assume that the CONEX mechanism will be used exclusively to signal >> the amount of congestion encountered by previous packets on the same >> flow >> b. Document the different uses to which that signal could be put >> (traffic management, incentivizing scavenger services, etc.) in the >> use cases draft >> c. Document how the signal is set in the mechanism draft > > This is certainly the approach in draft-ietf-conex-concepts-uses and the > co-authors of that document assumed this was what the charter was looking > for. Agreed. >> Approach #2: >> a. Assume that the metric that CONEX will signal is open for >> discussion, or that the mechanism may signal multiple different metrics >> b. Document use cases for a variety of different potential metrics in >> the use cases draft (congestion encountered previously on same flow, >> long-term user burstiness as you describe above, possibly others) >> c. Document how network nodes could respond to CONEX signals to >> effectuate particular outcomes (dropping more traffic from non-bursty >> users as you describe above) > > The potential problem with this approach is that there is no end to the > possible metrics that we could explore. In theory we are meant to be > submitting the Use Cases document by March this year! So we do need to > be sensible about what is in and out of scope. While I believe there's still some room for discussion what we mean by "congestion", I don't believe there's any room (left) for discussion that we mean to record anything other than congestion expected during transit of the packet in question (with some wiggle room for quantized encoding a-la ECN). There just aren't enough bits. ConEx-aware boxes along the way are _very_ likely to aggregate our ConEx markings, over time and/or over flows. A use-cases document can discuss such things, whereas a mechanism document is probably more limited. >> It seems as though you are taking approach #2 whereas others may be >> taking approach #1, and these two approaches probably need to be >> reconciled. I don't see how the same mechanism can signal both >> congestion previously experienced on the path and peak/average >> sending rate (although I'm happy for you or someone else to explain >> how it can be done). If it can't be done, then it seems like we are >> talking about signaling two different metrics. IMHO, discussion of a use-cases document has some leeway here -- not in what the metric will signal, but in what may be done based on aggregations of that metric. I do not believe Dave McDysan has exceeded that leeway -- though discussing use-cases in the absence of an agreed metric _does_ tend to lead to confusion... > I certainly favour approach 1, and this seems to better match with our > charter. On the other hand there is potential for looking at broader > definitions of congestion within the use cases document. One of the > big issues facing the WG is defining congestion in a sensible fashion. Clearly, we do have to produce a use-cases document, though I would prefer that at least an "abstract mechanism" could be agreed to as a basis for it. I tend to take a long-term view which says whatever we settle on for a mechanism should allow for future extensions. (Thus I am very much at home with desires for different ways to measure "congestion".) >> If we are focused on a single metric, then I think we need to document >> use cases for that metric. If there are multiple metrics, we should be >> clear about which use cases make use of which metric. And in either >> case, I thought the point of the mechanism draft was to explain how >> the chosen metric is measured so that it can be encoded at the IP >> layer. I am hesitant to go the path of labeling use-cases according to what metric best serves them. IMHO, our use-cases document should only include things achievable with a particular metric, which I have been assuming to be congestion-expected-during-transit. I do spend time thinking about "concrete" mechanisms, but I'm not sure it would help to discuss them now. Certainly such discussion doesn't belong in this thread. > I favour concentrating on a single metric relating as closely as possible > to "real" congestion. But Dave does have a very valid point - for > whatever reason, many ISPs use a shaper to rate limit traffic to/from > their customers. I would argue that at peak times this is probably not > the limiting factor, but off-peak it will be the biggest source of > apparent loss/congestion. Certainly, ConEx will need to operate in an environment where such "shaping" occurs. I am considerably less sure how (if at all) it should be discussed in a use-cases document. To me, it is "congestion" even if it is not resource-congestion. Congestion-expected markings could better inform decisions about "shaping". The issues about whether ConEx marking is considered at any point of congestion are much the same... > One interesting thought experiment - what if, instead of a shaper, the > ISP introduces a congestion marking system. Then it can rate limit > traffic by marking it before the traffic needs to be disrupted. The > only problem then is how to deal with non-responsive traffic. That undoubtedly deserves its own thread! -- John Leslie From dave.mcdysan@verizon.com Mon Feb 28 17:29:21 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20323A6D51 for ; Mon, 28 Feb 2011 17:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnX9DVf3ULNg for ; Mon, 28 Feb 2011 17:29:20 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 8723C3A6D5F for ; Mon, 28 Feb 2011 17:29:20 -0800 (PST) Received: from fldsmtpi02.verizon.com ([166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p211UJmi019837 for ; Mon, 28 Feb 2011 20:30:21 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,244,1297036800"; d="scan'208";a="2970663" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 01 Mar 2011 01:30:19 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 28 Feb 2011 20:30:19 -0500 To: Alissa Cooper Date: Mon, 28 Feb 2011 20:30:15 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvXsDl7JbnderRySQymA/f2/Mm2Ng== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2011 01:29:21 -0000 Hi Alissa, Some responses in line below. Thanks, Dave On 2/26/11 7:21 AM, "Alissa Cooper" wrote: >Hi Dave, > >Couple of questions inline... > >On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: >> The proposed measure from the text that Toby sent from my draft for >> this >> use case is that of burstiness (I.e., peak/average) where the >> incentive >> peak is the"flat rate" or "bandwidth tier" purchased. >> ... >> >> Let me illustrate by an example. If conex could send longer-term user >> burstiness to the congested shared resource, then a mechanism (to be >> described in the mechanism draft) at that point could >> drop more traffic from class B non-bursty users so that bandwidth >> tends >> to equalize between the two user classes >> Implement a bandwidth tier AND burst duration pricing scheme, with >> appropriate mechanisms to provide a burst duration longer than the >> shapers >> widely used today >> > >It seems to me that there are two different approaches being taken to >what is or is not in scope for both the use cases and the mechanism >definition: > >Approach #1: >a. Assume that the CONEX mechanism will be used exclusively to signal >the amount of congestion encountered by previous packets on the same >flow >b. Document the different uses to which that signal could be put >(traffic management, incentivizing scavenger services, etc.) in the >use cases draft >c. Document how the signal is set in the mechanism draft > >Approach #2: >a. Assume that the metric that CONEX will signal is open for >discussion, or that the mechanism may signal multiple different metrics >b. Document use cases for a variety of different potential metrics in >the use cases draft (congestion encountered previously on same flow, >long-term user burstiness as you describe above, possibly others) >c. Document how network nodes could respond to CONEX signals to >effectuate particular outcomes (dropping more traffic from non-bursty >users as you describe above) > >It seems as though you are taking approach #2 whereas others may be >taking approach #1, and these two approaches probably need to be >reconciled. I don't see how the same mechanism can signal both >congestion previously experienced on the path and peak/average sending >rate (although I'm happy for you or someone else to explain how it can >be done). If it can't be done, then it seems like we are talking about >signaling two different metrics. > >If we are focused on a single metric, then I think we need to document >use cases for that metric. If there are multiple metrics, we should be >clear about which use cases make use of which metric. And in either >case, I thought the point of the mechanism draft was to explain how >the chosen metric is measured so that it can be encoded at the IP layer. > >Alissa Quoting from the IETF 70 meeting minutes "ConEx Concepts and Abstract Mechanism draft-mathis-conex-abstract-mech-00 " Snipped " MB - not asking about sending to IESG, just asking about adoption - do people have comments? =20 Dave McDysan (DM) - charter related question - first result is usage scenarios document - other docs will not see publication until that is done - have already had questions on list about additional use cases. if we adopt this as the mechanism document then we foreclose use-case discussion. there are use cases being elaborated that aren't supported by the mechanism, so we could be going round in circles here. =20 MB - are you envisioning additional use cases that could not be satisfied by this mechanism? =20 DM - yes =20 MB - is this a little different or a lot? =20 DM - could be a lot different. this is a good approach for short timescales, but could do something longer term, slow path. =20 MB - so you would like to agree use cases? =20 Leslie Daigle (LD) - i would like to support adopting mechanism document. just don't use it as a blunt instrument to bludgeon people proposing new use cases. =20 MB - would that work for DM? =20 DM - yes, if that decision can be documented. =20 MB - yes, it will be documented, I will remember." I interpreted the above as something like Approach 2 was acceptable -- a use case did not need to align with the currently documented abstract mechanism. If others have a different interpretation, please respond to the list. Also, the way the prior version of the use case draft was written was closely tied to the (re-ECN) mechanism (Approach 1) and the agreement from the IETF 78 meeting minutes was to separate these. I provided a detailed set of comments toward this end. > >> >> Thanks, >> >> Dave >> >> >> On 2/24/11 5:11 PM, "John Leslie" wrote: >> >>> STUART VENTERS wrote: >>>> >>>> Let me make sure I understand this use case and it's desired >>>> outcome: >>>> >>>> Consider 2 users A, and B. >>>> A sends at a low rate all the time. >>>> B sends only a congestion causing bunch during busy times. >>>> A sends many more bytes per month than B >>>> >>>> Which is the 'heavy' user (I think B)? >>> >>> I don't think we should assume that... >>> >>>> Are we looking for a way for service providers to determine >>>> 'equitable' >>>> costs for these behaviors, or a way to make the system forwarding >>>> behavior for these two load is somehow 'equitable'? >>> >>> To some degree, Dave has to speak for himself, but IMHO this issue >>> is >>> about being able (under ConEx) to better inform a provider's >>> decision. >>> I'm nearly positive Dave doesn't mean for us to argue what balance >>> between >>> these two is "equitable". >>> >>> At first blush, it would seem "B" should "expect" congestion losses, >>> while "A" might not. Current non-ConEx methods tend to punish "A" >>> more >>> than "B"; and I do suspect Dave is suggesting a different balance >>> might >>> be appropriate. >>> >>> Nonetheless, IMHO "A" should expect congestion losses to increase >>> during periods of heavy use -- unless s/he buys better-than the >>> vanilla >>> best-effort service. >>> >>> -- >>> John Leslie >>> _______________________________________________ >>> 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 >> > From dave.mcdysan@verizon.com Mon Feb 28 17:37:11 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280B93A6D6B for ; Mon, 28 Feb 2011 17:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6xdTgrJ2uZQ for ; Mon, 28 Feb 2011 17:37:09 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id B4C173A6D6D for ; Mon, 28 Feb 2011 17:37:07 -0800 (PST) Received: from fldsmtpi01.verizon.com ([166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p211c79P003198 for ; Mon, 28 Feb 2011 20:38:07 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,244,1297036800"; d="scan'208";a="2965508" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 01 Mar 2011 01:38:06 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 28 Feb 2011 20:38:06 -0500 To: Toby Moncaster , "'Alissa Cooper'" Date: Mon, 28 Feb 2011 20:38:01 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvXsU/O9juFVWO4THy4DON1o/yR+Q== Message-ID: In-Reply-To: <001201cbd5b3$b5114020$1f33c060$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2011 01:37:11 -0000 Hi Toby, A few responses in line below. Thanks, Dave On 2/26/11 7:50 AM, "Toby Moncaster" wrote: > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of Alissa Cooper >> Sent: 26 February 2011 12:21 >> To: Mcdysan, David E >> Cc: conex@ietf.org >> Subject: Re: [conex] Discussion of new Use Cases pt 1 >>=20 >> Hi Dave, >>=20 >> Couple of questions inline... >>=20 >> On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote: >> > The proposed measure from the text that Toby sent from my draft for >> > this >> > use case is that of burstiness (I.e., peak/average) where the >> > incentive >> > peak is the"flat rate" or "bandwidth tier" purchased. >> > ... >> > >> > Let me illustrate by an example. If conex could send longer-term user >> > burstiness to the congested shared resource, then a mechanism (to be >> > described in the mechanism draft) at that point could >> > drop more traffic from class B non-bursty users so that bandwidth >> > tends >> > to equalize between the two user classes >> > Implement a bandwidth tier AND burst duration pricing scheme, with >> > appropriate mechanisms to provide a burst duration longer than the >> > shapers >> > widely used today >> > >>=20 >> It seems to me that there are two different approaches being taken to >> what is or is not in scope for both the use cases and the mechanism >> definition: >>=20 >> Approach #1: >> a. Assume that the CONEX mechanism will be used exclusively to signal >> the amount of congestion encountered by previous packets on the same >> flow >> b. Document the different uses to which that signal could be put >> (traffic management, incentivizing scavenger services, etc.) in the >> use cases draft >> c. Document how the signal is set in the mechanism draft > >This is certainly the approach in draft-ietf-conex-concepts-uses and the >co-authors of that document assumed this was what the charter was looking >for. See my response to Allison and the meeting minutes from IETF 79 and IETF 78.=20 > >>=20 >> Approach #2: >> a. Assume that the metric that CONEX will signal is open for >> discussion, or that the mechanism may signal multiple different metrics >> b. Document use cases for a variety of different potential metrics in >> the use cases draft (congestion encountered previously on same flow, >> long-term user burstiness as you describe above, possibly others) >> c. Document how network nodes could respond to CONEX signals to >> effectuate particular outcomes (dropping more traffic from non-bursty >> users as you describe above) > >The potential problem with this approach is that there is no end to the >possible metrics that we could explore. In theory we are meant to be >submitting the Use Cases document by March this year! So we do need to be >sensible about what is in and out of scope. > >>=20 >> It seems as though you are taking approach #2 whereas others may be >> taking approach #1, and these two approaches probably need to be >> reconciled. I don't see how the same mechanism can signal both >> congestion previously experienced on the path and peak/average sending >> rate (although I'm happy for you or someone else to explain how it can >> be done). If it can't be done, then it seems like we are talking about >> signaling two different metrics. > >I certainly favour approach 1, and this seems to better match with our >charter. On the other hand there is potential for looking at broader >definitions of congestion within the use cases document. One of the big >issues facing the WG is defining congestion in a sensible fashion. > >I agree that Dave's peak/average rate signal doesn't seem to fit into the >same sort of signalling framework. For one thing Dave seems to just imply >this would be a binary state. I.m not sure I understand this comment. Could you please expand on what are the states.=20 >However I think it may be possible to derive >something that gives the same information as Dave is looking for without >needing an additional explicit signal. This is a good example of how I would see the use case and mechanism drafts inter-relating. If the same mechanism signaling can be used to meet other use cases, then IMHO then this makes the abstract mechanism more attractive. However, if the use case cannot be (well) handled by the abstract mechanism, then that is also useful information. > >>=20 >> If we are focused on a single metric, then I think we need to document >> use cases for that metric. If there are multiple metrics, we should be >> clear about which use cases make use of which metric. And in either >> case, I thought the point of the mechanism draft was to explain how >> the chosen metric is measured so that it can be encoded at the IP >> layer. > >I favour concentrating on a single metric relating as closely as possible >to >"real" congestion. But Dave does have a very valid point - for whatever >reason, many ISPs use a shaper to rate limit traffic to/from their >customers. I would argue that at peak times this is probably not the >limiting factor, but off-peak it will be the biggest source of apparent >loss/congestion. And as I tried to describe in my Beijing draft, in certain growth and restoration scenarios off-peak is the majority of elapsed network equipment deployment time. > >One interesting thought experiment - what if, instead of a shaper, the ISP >introduces a congestion marking system. Then it can rate limit traffic by >marking it before the traffic needs to be disrupted. The only problem then >is how to deal with non-responsive traffic. This idea is not complete, but I think it is in the direction I mentioned above of having a description of how one mechanism could be used in a different way to meet the needs of a use case. > >Toby > >>=20 >> Alissa >>=20 >> > >> > Thanks, >> > >> > Dave >> > >> > >> > On 2/24/11 5:11 PM, "John Leslie" wrote: >> > >> >> STUART VENTERS wrote: >> >>> >> >>> Let me make sure I understand this use case and it's desired >> >>> outcome: >> >>> >> >>> Consider 2 users A, and B. >> >>> A sends at a low rate all the time. >> >>> B sends only a congestion causing bunch during busy times. >> >>> A sends many more bytes per month than B >> >>> >> >>> Which is the 'heavy' user (I think B)? >> >> >> >> I don't think we should assume that... >> >> >> >>> Are we looking for a way for service providers to determine >> >>> 'equitable' >> >>> costs for these behaviors, or a way to make the system forwarding >> >>> behavior for these two load is somehow 'equitable'? >> >> >> >> To some degree, Dave has to speak for himself, but IMHO this issue >> >> is >> >> about being able (under ConEx) to better inform a provider's >> >> decision. >> >> I'm nearly positive Dave doesn't mean for us to argue what balance >> >> between >> >> these two is "equitable". >> >> >> >> At first blush, it would seem "B" should "expect" congestion >> losses, >> >> while "A" might not. Current non-ConEx methods tend to punish "A" >> >> more >> >> than "B"; and I do suspect Dave is suggesting a different balance >> >> might >> >> be appropriate. >> >> >> >> Nonetheless, IMHO "A" should expect congestion losses to increase >> >> during periods of heavy use -- unless s/he buys better-than the >> >> vanilla >> >> best-effort service. >> >> >> >> -- >> >> John Leslie >> >> _______________________________________________ >> >> 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 >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > From dave.mcdysan@verizon.com Mon Feb 28 18:06:04 2011 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB6A3A695E for ; Mon, 28 Feb 2011 18:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H67vEpHHv4aq for ; Mon, 28 Feb 2011 18:06:03 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 599533A6959 for ; Mon, 28 Feb 2011 18:06:03 -0800 (PST) Received: from fldsmtpi01.verizon.com ([166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p2126oCp014059 for ; Mon, 28 Feb 2011 21:07:05 -0500 (EST) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.62,245,1297036800"; d="scan'208";a="2973259" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 01 Mar 2011 02:06:50 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.147]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Mon, 28 Feb 2011 21:06:50 -0500 To: John Leslie , Toby Moncaster Date: Mon, 28 Feb 2011 21:06:44 -0500 Thread-Topic: [conex] Discussion of new Use Cases pt 1 Thread-Index: AcvXtVNtgiHSiJT/RiCBItMCFNFzjA== Message-ID: In-Reply-To: <20110226145616.GH7663@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Discussion of new Use Cases pt 1 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2011 02:06:04 -0000 Hi John, Some responses in line below. Dave On 2/26/11 9:56 AM, "John Leslie" wrote: >Toby Moncaster wrote: >> To: "'Alissa Cooper'" , >>=20 >>> It seems to me that there are two different approaches being taken to >>> what is or is not in scope for both the use cases and the mechanism >>> definition: >>>=20 >>> Approach #1: >>> a. Assume that the CONEX mechanism will be used exclusively to signal >>> the amount of congestion encountered by previous packets on the same >>> flow >>> b. Document the different uses to which that signal could be put >>> (traffic management, incentivizing scavenger services, etc.) in the >>> use cases draft >>> c. Document how the signal is set in the mechanism draft >>=20 >> This is certainly the approach in draft-ietf-conex-concepts-uses and the >> co-authors of that document assumed this was what the charter was >>looking >> for. > > Agreed. > >>> Approach #2: >>> a. Assume that the metric that CONEX will signal is open for >>> discussion, or that the mechanism may signal multiple different metrics >>> b. Document use cases for a variety of different potential metrics in >>> the use cases draft (congestion encountered previously on same flow, >>> long-term user burstiness as you describe above, possibly others) >>> c. Document how network nodes could respond to CONEX signals to >>> effectuate particular outcomes (dropping more traffic from non-bursty >>> users as you describe above) >>=20 >> The potential problem with this approach is that there is no end to the >> possible metrics that we could explore. In theory we are meant to be >> submitting the Use Cases document by March this year! So we do need to >> be sensible about what is in and out of scope. > > While I believe there's still some room for discussion what we mean >by "congestion", I don't believe there's any room (left) for discussion >that we mean to record anything other than congestion expected during >transit of the packet in question (with some wiggle room for quantized >encoding a-la ECN). There just aren't enough bits. > > ConEx-aware boxes along the way are _very_ likely to aggregate our >ConEx markings, over time and/or over flows. A use-cases document can >discuss such things, whereas a mechanism document is probably more >limited. Good point. I think this is the general direction that Marcello may have had in mind when he commented during my presentation in Beijing. Not sure what Marcello, Rich or Bob had in mind here as discussed in the meeting minutes. I suggest that we need to work toward some proposed text for the wg use case draft that describes this. > >>> It seems as though you are taking approach #2 whereas others may be >>> taking approach #1, and these two approaches probably need to be >>> reconciled. I don't see how the same mechanism can signal both >>> congestion previously experienced on the path and peak/average >>> sending rate (although I'm happy for you or someone else to explain >>> how it can be done). If it can't be done, then it seems like we are >>> talking about signaling two different metrics. > > IMHO, discussion of a use-cases document has some leeway here -- >not in what the metric will signal, but in what may be done based on >aggregations of that metric. I do not believe Dave McDysan has exceeded >that leeway -- though discussing use-cases in the absence of an agreed >metric _does_ tend to lead to confusion... > >> I certainly favour approach 1, and this seems to better match with our >> charter. On the other hand there is potential for looking at broader >> definitions of congestion within the use cases document. One of the >> big issues facing the WG is defining congestion in a sensible fashion. > > Clearly, we do have to produce a use-cases document, though I would >prefer that at least an "abstract mechanism" could be agreed to as a >basis for it. Not sure I understand what you are proposing. The wg decided to take mechanism largely out of the use case draft in IETF 78, and in IETF 79 the exclusion of a use case that did not match the adopted abstract mechanism was explicitly agreed (see meeting minutes snippet in my response to Allison). > I tend to take a long-term view which says whatever we settle on for >a mechanism should allow for future extensions. (Thus I am very much >at home with desires for different ways to measure "congestion".) > >>> If we are focused on a single metric, then I think we need to document >>> use cases for that metric. If there are multiple metrics, we should be >>> clear about which use cases make use of which metric. And in either >>> case, I thought the point of the mechanism draft was to explain how >>> the chosen metric is measured so that it can be encoded at the IP >>> layer. > > I am hesitant to go the path of labeling use-cases according to what >metric best serves them. IMHO, our use-cases document should only include >things achievable with a particular metric, which I have been assuming >to be congestion-expected-during-transit. Metric is mentioned once in the use case document in section 3 in the context of existing approaches. Are you referring to the measures in definitions of use cases, or something in the abstract mechanism draft? (where the term metric is not used at all) > > I do spend time thinking about "concrete" mechanisms, but I'm not sure >it would help to discuss them now. Certainly such discussion doesn't >belong in this thread. > >> I favour concentrating on a single metric relating as closely as >>possible >> to "real" congestion. But Dave does have a very valid point - for >> whatever reason, many ISPs use a shaper to rate limit traffic to/from >> their customers. I would argue that at peak times this is probably not >> the limiting factor, but off-peak it will be the biggest source of >> apparent loss/congestion. > > Certainly, ConEx will need to operate in an environment where such >"shaping" occurs. I am considerably less sure how (if at all) it should >be discussed in a use-cases document. I asked this question in IETF 78 of Bob regarding a non-work conserving scheduler (e.g., shaper), which can experiences the congestion measure as defined in the current use case draft. At a minimum I think the statement in the first paragraph of section 4 that describes what I called "inter-user congestion" as "---- congestion means that your traffic impacts other users, and conversely that their traffic impacts you." needs to exclude the use case of what I called "self-congestion" needs to address the use case employed by many ISPs (as Toby points out). >To me, it is "congestion" even if >it is not resource-congestion. Congestion-expected markings could better >inform decisions about "shaping". The issues about whether ConEx marking >is considered at any point of congestion are much the same... I didn't follow this. Could you please elaborate. > >> One interesting thought experiment - what if, instead of a shaper, the >> ISP introduces a congestion marking system. Then it can rate limit >> traffic by marking it before the traffic needs to be disrupted. The >> only problem then is how to deal with non-responsive traffic. > > That undoubtedly deserves its own thread! > >-- >John Leslie