From marcelo@it.uc3m.es Mon Jun 6 09:06:13 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6911E8166 for ; Mon, 6 Jun 2011 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92KMa4FUf3I4 for ; Mon, 6 Jun 2011 09:06:13 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id A8F8D11E8164 for ; Mon, 6 Jun 2011 09:06:12 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (unknown [163.117.203.233]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 3DAD6C28356 for ; Mon, 6 Jun 2011 18:06:06 +0200 (CEST) Message-ID: <4DECFAED.4040104@it.uc3m.es> Date: Mon, 06 Jun 2011 18:06:05 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 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-18184.000 Subject: [conex] agenda requests for ietf81 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:06:13 -0000 We plan to have a meeting in the next ietf, please send us the requests asap. Regards, marcelo From bob.briscoe@bt.com Tue Jun 14 09:20:56 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8931F0C36 for ; Tue, 14 Jun 2011 09:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WspxoM6Pvrem for ; Tue, 14 Jun 2011 09:20:55 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 46B001F0C3C for ; Tue, 14 Jun 2011 09:20:50 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 17:20:48 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 17:20:48 +0100 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 1308068447851; Tue, 14 Jun 2011 17:20:47 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5EGKj1i027257; Tue, 14 Jun 2011 17:20:45 +0100 Message-Id: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 17:20:45 +0100 To: ConEx IETF list From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2011 16:20:48.0479 (UTC) FILETIME=[056106F0:01CC2AAF] Subject: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:20:56 -0000 ConEx folks, After the last IETF in Prague, we agreed to work on a revised draft-ietf-conex-concepts-uses. We're planning on using a lot of the text as is, but we suggested that the Introduction needed a complete re-write. Below is our joint proposal. Please bash. Rationale for this Introduction: =============================== * The main change is a shift to the main target use-case in the body of the document: traffic management, leaving defining congestion etc to the definitions and concepts section (section 2). * Introduce enough of the solution to allow the reader to grasp the main logic. * Introduce one primary use and mention there are others - to keep focused but hint at breadth. * Start to weave in some benefits bullet points (transparency, neutrality). * Hint at controversies like the over-provisioning issue in the first para, but leave addressing this to later, when we can go into the subject properly. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 1. Introduction The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators usually provide sufficient capacity, but whenever too much packet load meets too little shared capacity, congestion results. Congestion appears as either increased delay, missing packets or packets explicitly marked with ECN [RFC3168]. The classic Internet architecture is arranged so that receivers detect such signs of congestion and feed them back end-to-end. Then, ideally, most senders reduce their rate in response. The purpose of this document is to motivate a new congestion exposure (ConEx) field at the IP layer. The idea is to add a third pass to the feedback loop so that the sender can relay congestion information back into the internetwork layer, exposing the level of congestion the sender expects packets to experience along their whole path (Figure 1). Then certain network nodes can use this new information at the IP layer, for example as input to traffic management. ,---------. ,---------. |Transport| |Transport| | Sender | |Receiver | | |<==Feedback=Path==============================<| | | ,---|<--Transport Layer returned Congestion Signal-<|<--. | | | | | | | | | | | | | | | | ,-----------. | | | | | | |(Congested)| | | | | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | | | | | Device |>-Congestion-Signal->|---' | | | | `-----------' | | | `-->|>---------(new) IP layer ConEx Signal--------->| | | | (Carried in Data Packet Headers) | | `---------' `---------' Figure 1: Where the ConEx Protocol Fits in the Internet Architecture This document serves as the entry point to the set of ConEx documentation, giving the 'why' rather than the 'how'. A companion document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. The main aim of ConEx is to support evolution of alternatives to the proliferation of traffic management solutions that are over- constraining, non-transparent and often not application-neutral. Traffic management ought to be able to leave end systems free to choose how to behave without undue interference, while simultaneously satisfying the main concern of network operators; to control traffic from some users that excessively limits the freedoms of others. Freedoms only actually collide when shared capacity becomes congested--when a link is full so that a greater share for one user would necessarily leave less for someone else. Current traffic management solutions typically limit volume or bit-rate in order to reduce the likelihood of congestion--limiting one thing in the hope it might limit another. However, there is no real need to count volume that is sent when there is no congestion, and there is no real need to limit bit-rate when there is no congestion. ConEx markings on packets add the missing information network operators need to get a handle on congestion itself. Then they can directly limit and control traffic based on how much it contributes to congestion and leave traffic unconstrained if it doesn't cause congestion. The idea is for the operator to be able to count and control the bulk volume or bit-rate of packets marked for congestion and disregard packets not contributing to congestion. With ConEx there is no need for the network provider to identify specific applications or behaviours at the flow level, because the relevant bulk congestion information is revealed at the network layer. Also, because ConEx information is added explicitly at the IP layer, it is visible to provider and consumer alike. Therefore traffic contracts or acceptable use policies can be based on a metric that is transparent to both parties and is sufficient to manage traffic without extra non-transparent wriggle-room and caveats. In summary, ConEx is designed to make it simple to do traffic management that is transparent, neutral and not over-constrained. Although there is no implication that network operators ought to provide such an unconstrained, transparent, neutral service, it certainly should not be impossible and ideally it should be the simplest service to provide. The IP layer is intended to engender new applications and behaviours and to work over all existing and new lower layer technologies. ConEx is a generative technology in this vein, with a range of potential uses. This document focuses initially on traffic management before widening out to introduce some additional important uses for ConEx as well as brifly mentioning a few others. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob Briscoe & Rich Woundy From menth@informatik.uni-tuebingen.de Tue Jun 14 09:56:42 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8611E807F for ; Tue, 14 Jun 2011 09:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW5tQdXE8V8Y for ; Tue, 14 Jun 2011 09:56:41 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 3489D11E808B for ; Tue, 14 Jun 2011 09:56:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8CB4E5267; Tue, 14 Jun 2011 18:56:34 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WujLpguukWkd; Tue, 14 Jun 2011 18:56:28 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D694A5240; Tue, 14 Jun 2011 18:56:27 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 66EF2117A46C; Tue, 14 Jun 2011 18:56:27 +0200 (CEST) Message-ID: <4DF792CB.5090207@informatik.uni-tuebingen.de> Date: Tue, 14 Jun 2011 18:56:43 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> In-Reply-To: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:56:42 -0000 Hi Bob, Am 14.06.2011 18:20, schrieb Bob Briscoe: > ConEx folks, > > After the last IETF in Prague, we agreed to work on a revised > draft-ietf-conex-concepts-uses. We're planning on using a lot of the > text as is, but we suggested that the Introduction needed a complete > re-write. Below is our joint proposal. > > Please bash. > > Rationale for this Introduction: > =============================== > * The main change is a shift to the main target use-case in the body > of the document: traffic management, leaving defining congestion etc > to the definitions and concepts section (section 2). > * Introduce enough of the solution to allow the reader to grasp the > main logic. > * Introduce one primary use and mention there are others - to keep > focused but hint at breadth. > * Start to weave in some benefits bullet points (transparency, > neutrality). > * Hint at controversies like the over-provisioning issue in the first > para, but leave addressing this to later, when we can go into the > subject properly. > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > 1. Introduction > > The power of Internet technology comes from multiplexing shared > capacity with packets rather than circuits. Network operators > usually provide sufficient capacity, but whenever too much packet > load meets too little shared capacity, congestion results. > Congestion appears as either increased delay, missing packets or > packets explicitly marked with ECN [RFC3168]. The classic Internet > architecture is arranged so that receivers detect such signs of > congestion and feed them back end-to-end. Then, ideally, most > senders reduce their rate in response. > > The purpose of this document is to motivate a new congestion exposure > (ConEx) field at the IP layer. The idea is to add a third pass to > the feedback loop so that the sender can relay congestion information > back into the internetwork layer, I think "IP layer" is more concrete > exposing the level of congestion > the sender expects packets to experience along their whole path > (Figure 1). I'd prefer if you integrate the Figure more into the text for describing Conex. This makes reading easier. > Then certain network nodes can use this new information > at the IP layer, for example as input to traffic management. > > ,---------. ,---------. > |Transport| |Transport| > | Sender | |Receiver | > | |<==Feedback=Path==============================<| | > | ,---|<--Transport Layer returned Congestion Signal-<|<--. | > | | | | | | > | | | | | | > | | | ,-----------. | | | > | | | |(Congested)| | | | > | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | > | | | | Device |>-Congestion-Signal->|---' | > | | | `-----------' | | > | `-->|>---------(new) IP layer ConEx Signal--------->| | > | | (Carried in Data Packet Headers) | | > `---------' `---------' > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > This document serves as the entry point to the set of ConEx > documentation, giving the 'why' rather than the 'how'. A companion > document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. > > The main aim of ConEx is to support evolution of alternatives to the > proliferation of traffic management solutions that are over- > constraining, non-transparent and often not application-neutral. > Traffic management ought to be able to leave end systems free to > choose how to behave without undue interference, while simultaneously > satisfying the main concern of network operators; to control traffic > from some users that excessively limits the freedoms of others. > > Freedoms only actually collide when shared capacity becomes > congested--when a link is full so that a greater share for one user > would necessarily leave less for someone else. Current traffic > management solutions typically limit volume or bit-rate in order to > reduce the likelihood of congestion--limiting one thing in the hope > it might limit another. However, there is no real need to count > volume that is sent when there is no congestion, and there is no real > need to limit bit-rate when there is no congestion. > > ConEx markings on packets add the missing information network > operators need to get a handle on congestion itself. Then they can > directly limit and control traffic based on how much it contributes > to congestion and leave traffic unconstrained if it doesn't cause > congestion. The idea is for the operator to be able to count and > control the bulk volume or bit-rate of packets marked for congestion > and disregard packets not contributing to congestion. > > With ConEx there is no need for the network provider to identify > specific applications or behaviours at the flow level, because the > relevant bulk congestion information is revealed at the network > layer. Better: IP layer? > Also, because ConEx information is added explicitly at the IP > layer, it is visible to provider and consumer alike. Therefore > traffic contracts or acceptable use policies can be based on a metric > that is transparent to both parties and is sufficient to manage > traffic without extra non-transparent wriggle-room and caveats. > > In summary, ConEx is designed to make it simple to do traffic > management that is transparent, neutral and not over-constrained. > Although there is no implication that network operators ought to > provide such an unconstrained, transparent, neutral service, it > certainly should not be impossible and ideally it should be the > simplest service to provide. This sentence is a bit complicated. Can you simplify? > > The IP layer is intended to engender new applications and behaviours > and to work over all existing and new lower layer technologies. > ConEx is a generative technology in this vein, with a range of > potential uses. This document focuses initially on traffic > management before widening out to introduce some additional important > uses for ConEx as well as brifly mentioning a few others. > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ I like this text about conex. However, I am not sure if one can fully follow if one doesn't have the "conex background". Regards, Michael > > > Bob Briscoe & Rich Woundy > > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From bob.briscoe@bt.com Tue Jun 14 11:04:01 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6D21F8488 for ; Tue, 14 Jun 2011 11:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3oaLBQwxSRB for ; Tue, 14 Jun 2011 11:04:00 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0646321F848A for ; Tue, 14 Jun 2011 11:03:59 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 19:03:58 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 19:03:58 +0100 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 1308074637372; Tue, 14 Jun 2011 19:03:57 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5EI3s4Y027835; Tue, 14 Jun 2011 19:03:55 +0100 Message-Id: <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 19:03:54 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF792CB.5090207@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> 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: 14 Jun 2011 18:03:58.0293 (UTC) FILETIME=[6ECBB050:01CC2ABD] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:04:01 -0000 Michael, Tx for the quick turn-round. Everything you suggest makes sense. I have pasted replacement paras in the thread below to satisfy these requests. At 17:56 14/06/2011, Michael Menth wrote: >Hi Bob, > >Am 14.06.2011 18:20, schrieb Bob Briscoe: >>ConEx folks, >> >>After the last IETF in Prague, we agreed to work on a revised >>draft-ietf-conex-concepts-uses. We're planning on using a lot of >>the text as is, but we suggested that the Introduction needed a >>complete re-write. Below is our joint proposal. >> >>Please bash. >> >>Rationale for this Introduction: >>=============================== >>* The main change is a shift to the main target use-case in the >>body of the document: traffic management, leaving defining >>congestion etc to the definitions and concepts section (section 2). >>* Introduce enough of the solution to allow the reader to grasp the >>main logic. >>* Introduce one primary use and mention there are others - to keep >>focused but hint at breadth. >>* Start to weave in some benefits bullet points (transparency, neutrality). >>* Hint at controversies like the over-provisioning issue in the >>first para, but leave addressing this to later, when we can go into >>the subject properly. >> >> >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>1. Introduction >I think "IP layer" is more concrete >I'd prefer if you integrate the Figure more into the text for >describing Conex. This makes reading easier. 1st two paras again: The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators usually provide sufficient capacity, but whenever too much packet load meets too little shared capacity, congestion results. Congestion appears as either increased delay, missing packets or packets explicitly marked with ECN [RFC3168]. The classic Internet architecture is arranged so that receivers detect such signs of congestion and feed them back end-to-end (shown at the middle and top of Figure 1). Then, ideally, most senders reduce their rate in response. The purpose of this document is to motivate a new congestion exposure (ConEx) field at the IP layer. The idea is to add a third pass to the feedback loop (shown at the bottom of Figure 1) so that the sender can relay congestion information back into the IP layer, exposing the level of congestion the sender expects packets to experience along their whole path. Then certain network nodes can use this new information at the IP layer, for example as input to traffic management. >> ,---------. ,---------. >> |Transport| |Transport| >> | Sender | |Receiver | >> | |<==Feedback=Path==============================<| | >> | ,---|<--Transport Layer returned Congestion Signal-<|<--. | >> | | | | | | >> | | | | | | >> | | | ,-----------. | | | >> | | | |(Congested)| | | | >> | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | >> | | | | Device |>-Congestion-Signal->|---' | >> | | | `-----------' | | >> | `-->|>---------(new) IP layer ConEx Signal--------->| | >> | | (Carried in Data Packet Headers) | | >> `---------' `---------' >> >> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >> >> This document serves as the entry point to the set of ConEx >> documentation, giving the 'why' rather than the 'how'. A companion >> document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. >> >> The main aim of ConEx is to support evolution of alternatives to the >> proliferation of traffic management solutions that are over- >> constraining, non-transparent and often not application-neutral. >> Traffic management ought to be able to leave end systems free to >> choose how to behave without undue interference, while simultaneously >> satisfying the main concern of network operators; to control traffic >> from some users that excessively limits the freedoms of others. >> >> Freedoms only actually collide when shared capacity becomes >> congested--when a link is full so that a greater share for one user >> would necessarily leave less for someone else. Current traffic >> management solutions typically limit volume or bit-rate in order to >> reduce the likelihood of congestion--limiting one thing in the hope >> it might limit another. However, there is no real need to count >> volume that is sent when there is no congestion, and there is no real >> need to limit bit-rate when there is no congestion. >> >> ConEx markings on packets add the missing information network >> operators need to get a handle on congestion itself. Then they can >> directly limit and control traffic based on how much it contributes >> to congestion and leave traffic unconstrained if it doesn't cause >> congestion. The idea is for the operator to be able to count and >> control the bulk volume or bit-rate of packets marked for congestion >> and disregard packets not contributing to congestion. >> >> With ConEx there is no need for the network provider to identify >> specific applications or behaviours at the flow level, because the >> relevant bulk congestion information is revealed at the network >> layer. >Better: IP layer? Done >>Also, because ConEx information is added explicitly at the IP >> layer, it is visible to provider and consumer alike. Therefore >> traffic contracts or acceptable use policies can be based on a metric >> that is transparent to both parties and is sufficient to manage >> traffic without extra non-transparent wriggle-room and caveats. >> >> In summary, ConEx is designed to make it simple to do traffic >> management that is transparent, neutral and not over-constrained. >> Although there is no implication that network operators ought to >> provide such an unconstrained, transparent, neutral service, it >> certainly should not be impossible and ideally it should be the >> simplest service to provide. >This sentence is a bit complicated. Can you simplify? I've edited it to: Although there is no implication that network operators ought to provide such an unconstrained, transparent, neutral service, it certainly should not be impossible. Ideally it should also be the simplest service to provide. >> The IP layer is intended to engender new applications and behaviours >> and to work over all existing and new lower layer technologies. >> ConEx is a generative technology in this vein, with a range of >> potential uses. This document focuses initially on traffic >> management before widening out to introduce some additional important >> uses for ConEx as well as brifly mentioning a few others. >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >I like this text about conex. However, I am not sure if one can >fully follow if one doesn't have the "conex background". Would it be better if we explicitly permit the reader to not 'get it' just by reading the Introduction. For example in para 2 we could add: "The purpose of this doc is to ++outline the concepts necessary to understand and++ motivate a new congestion exposure (ConEx) field at the IP layer" And further down: " The ++rather radical++ idea is for the operator to be able to count and control the bulk volume or bit-rate of packets marked for congestion and disregard packets not contributing to congestion." ? Bob >Regards, > > Michael > > >> >> >>Bob Briscoe & Rich Woundy >> >> >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bauer@mit.edu Tue Jun 14 11:34:10 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D1211E8151 for ; Tue, 14 Jun 2011 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ8cVurpOMet for ; Tue, 14 Jun 2011 11:34:09 -0700 (PDT) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3B45611E8102 for ; Tue, 14 Jun 2011 11:34:09 -0700 (PDT) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1QWYRE-000385-JN for conex@ietf.org; Tue, 14 Jun 2011 14:34:08 -0400 Received: by iwn39 with SMTP id 39so6675578iwn.31 for ; Tue, 14 Jun 2011 11:34:08 -0700 (PDT) Received: by 10.43.132.66 with SMTP id ht2mr8692221icc.339.1308076448110; Tue, 14 Jun 2011 11:34:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.241.200 with HTTP; Tue, 14 Jun 2011 11:33:38 -0700 (PDT) In-Reply-To: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> From: Steve Bauer Date: Tue, 14 Jun 2011 14:33:38 -0400 Message-ID: To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:34:10 -0000 > =A0 Traffic management ought to be able to leave end systems free to > =A0 choose how to behave without undue interference, while simultaneously > =A0 satisfying the main concern of network operators; to control traffic > =A0 from some users that excessively limits the freedoms of others. > > =A0 Freedoms only actually collide when shared capacity becomes > =A0 congested--when a link is full so that a greater share for one user > =A0 would necessarily leave less for someone else. One part that caused me to wince was the discussion of "freedoms". I don't want to equate congesting a link with stomping on other's liberty. You must mean this in a technical sense, so I would use language that is less loaded. Or maybe you deliberately choose "freedom" here? I do understand that these paragraphs are getting to the core of the motivation... I would have perhaps said "the main concern of network operators" was "to control traffic from some users that disproportionately cause congestion." And then maybe just strike the first sentence of the following paragraph which also discusses "freedoms". -Steve From bob.briscoe@bt.com Tue Jun 14 11:55:50 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D00611E8151 for ; Tue, 14 Jun 2011 11:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol4hwz6qltrW for ; Tue, 14 Jun 2011 11:55:49 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9811E80EA for ; Tue, 14 Jun 2011 11:55:48 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 19:55:47 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 19:55:47 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1308077746857; Tue, 14 Jun 2011 19:55:46 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5EItj0x028109; Tue, 14 Jun 2011 19:55:46 +0100 Message-Id: <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 19:55:43 +0100 To: Steve Bauer From: Bob Briscoe In-Reply-To: References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2011 18:55:47.0942 (UTC) FILETIME=[AC4A7860:01CC2AC4] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:55:50 -0000 Steve, I see the problem - we tried to link back to the first mention of the word 'free', but the text could be misconstrued to mean freedom of information, freedom of speech, freedom of association etc, not just freedom at the traffic behaviour level. How about: " Traffic management ought to be able to leave end systems free to choose how to behave without undue interference, while simultaneously satisfying the main concern of network operators; to control traffic from some users that excessively limits the freedom of others to send how they want. These freedoms only actually collide when shared capacity becomes congested... " Bob At 19:33 14/06/2011, Steve Bauer wrote: > > Traffic management ought to be able to leave end systems free to > > choose how to behave without undue interference, while simultaneously > > satisfying the main concern of network operators; to control traffic > > from some users that excessively limits the freedoms of others. > > > > Freedoms only actually collide when shared capacity becomes > > congested--when a link is full so that a greater share for one user > > would necessarily leave less for someone else. > >One part that caused me to wince was the discussion of "freedoms". I >don't want to equate congesting a link with stomping on other's >liberty. You must mean this in a technical sense, so I would use >language that is less loaded. > >Or maybe you deliberately choose "freedom" here? I do understand that >these paragraphs are getting to the core of the motivation... > >I would have perhaps said "the main concern of network operators" was >"to control traffic from some users that disproportionately cause >congestion." And then maybe just strike the first sentence of the >following paragraph which also discusses "freedoms". > >-Steve ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Tue Jun 14 13:06:30 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3521F858E for ; Tue, 14 Jun 2011 13:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPZnmRQgPxpB for ; Tue, 14 Jun 2011 13:06:30 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 61AA121F858C for ; Tue, 14 Jun 2011 13:06:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C0DA952DA; Tue, 14 Jun 2011 22:06:25 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcTr4OHN-E97; Tue, 14 Jun 2011 22:06:20 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 785DD52BD; Tue, 14 Jun 2011 22:06:20 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7DE8D1E001ED; Tue, 14 Jun 2011 22:06:19 +0200 (CEST) Message-ID: <4DF7BF43.1050104@informatik.uni-tuebingen.de> Date: Tue, 14 Jun 2011 22:06:27 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> In-Reply-To: <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:06:30 -0000 Hi Bob, Am 14.06.2011 20:55, schrieb Bob Briscoe: > Steve, > > I see the problem - we tried to link back to the first mention of the > word 'free', but the text could be misconstrued to mean freedom of > information, freedom of speech, freedom of association etc, not just > freedom at the traffic behaviour level. > > How about: > " Traffic management ought to be able to leave end systems free to > choose how to behave without undue interference, while simultaneously > satisfying the main concern of network operators; to control traffic > from some users that excessively limits the freedom of others to send > how they want. > > These freedoms only actually collide when shared capacity becomes > congested... > " I understand this paragraph only as I am in the meantime used to this special wording that is relatively far from technical. Problems to catch the meaning can be: "without undue interference" is not necessarily clear what it means. Also the story with "freedom" and "freedoms collide" is quite metaphoric. I know now what this means, but it's not so easy for newbies. Regards, Michael > > > > Bob > > At 19:33 14/06/2011, Steve Bauer wrote: >> > Traffic management ought to be able to leave end systems free to >> > choose how to behave without undue interference, while >> simultaneously >> > satisfying the main concern of network operators; to control traffic >> > from some users that excessively limits the freedoms of others. >> > >> > Freedoms only actually collide when shared capacity becomes >> > congested--when a link is full so that a greater share for one user >> > would necessarily leave less for someone else. >> >> One part that caused me to wince was the discussion of "freedoms". I >> don't want to equate congesting a link with stomping on other's >> liberty. You must mean this in a technical sense, so I would use >> language that is less loaded. >> >> Or maybe you deliberately choose "freedom" here? I do understand that >> these paragraphs are getting to the core of the motivation... >> >> I would have perhaps said "the main concern of network operators" was >> "to control traffic from some users that disproportionately cause >> congestion." And then maybe just strike the first sentence of the >> following paragraph which also discusses "freedoms". >> >> -Steve > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Tue Jun 14 13:10:21 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BD31F0C3D for ; Tue, 14 Jun 2011 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9wglYzH7ZhI for ; Tue, 14 Jun 2011 13:10:18 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id EFA3D1F0C3C for ; Tue, 14 Jun 2011 13:10:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id D15AF52DA; Tue, 14 Jun 2011 22:10:15 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En7XXbMmy0n3; Tue, 14 Jun 2011 22:10:13 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 42A1252BD; Tue, 14 Jun 2011 22:10:13 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6D791117B390; Tue, 14 Jun 2011 22:10:12 +0200 (CEST) Message-ID: <4DF7C02C.2020505@informatik.uni-tuebingen.de> Date: Tue, 14 Jun 2011 22:10:20 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> In-Reply-To: <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:10:22 -0000 Hi Bob, Am 14.06.2011 20:03, schrieb Bob Briscoe: > Michael, > > Tx for the quick turn-round. > > Everything you suggest makes sense. I have pasted replacement paras in > the thread below to satisfy these requests. > > At 17:56 14/06/2011, Michael Menth wrote: >> Hi Bob, >> >> Am 14.06.2011 18:20, schrieb Bob Briscoe: >>> ConEx folks, >>> >>> After the last IETF in Prague, we agreed to work on a revised >>> draft-ietf-conex-concepts-uses. We're planning on using a lot of the >>> text as is, but we suggested that the Introduction needed a complete >>> re-write. Below is our joint proposal. >>> >>> Please bash. >>> >>> Rationale for this Introduction: >>> =============================== >>> * The main change is a shift to the main target use-case in the body >>> of the document: traffic management, leaving defining congestion etc >>> to the definitions and concepts section (section 2). >>> * Introduce enough of the solution to allow the reader to grasp the >>> main logic. >>> * Introduce one primary use and mention there are others - to keep >>> focused but hint at breadth. >>> * Start to weave in some benefits bullet points (transparency, >>> neutrality). >>> * Hint at controversies like the over-provisioning issue in the >>> first para, but leave addressing this to later, when we can go into >>> the subject properly. >>> >>> >>> >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>> 1. Introduction >> I think "IP layer" is more concrete >> I'd prefer if you integrate the Figure more into the text for >> describing Conex. This makes reading easier. > > 1st two paras again: > > The power of Internet technology comes from multiplexing shared > capacity with packets rather than circuits. Network operators > usually provide sufficient capacity, but whenever too much packet > load meets too little shared capacity, congestion results. > Congestion appears as either increased delay, missing packets or > packets explicitly marked with ECN [RFC3168]. The classic Internet > architecture is arranged so that receivers detect such signs of > congestion and feed them back end-to-end (shown at the middle and top > of Figure 1). Then, ideally, most senders reduce their rate in > response. > > The purpose of this document is to motivate a new congestion exposure > (ConEx) field at the IP layer. The idea is to add a third pass to > the feedback loop (shown at the bottom of Figure 1) so that the > sender can relay congestion information back into the IP layer, > exposing the level of congestion the sender expects packets to > experience along their whole path. Then certain network nodes can > use this new information at the IP layer, for example as input to > traffic management. Great! > > >>> ,---------. >>> ,---------. >>> |Transport| >>> |Transport| >>> | Sender | >>> |Receiver | >>> | >>> |<==Feedback=Path==============================<| | >>> | ,---|<--Transport Layer returned Congestion >>> Signal-<|<--. | >>> | | | | >>> | | >>> | | | | >>> | | >>> | | | ,-----------. | >>> | | >>> | | | |(Congested)| | >>> | | >>> | | |>=Data=Path=>| Network |>=====Data=Path=====>| >>> | | >>> | | | | Device >>> |>-Congestion-Signal->|---' | >>> | | | `-----------' >>> | | >>> | `-->|>---------(new) IP layer ConEx >>> Signal--------->| | >>> | | (Carried in Data Packet Headers) >>> | | >>> `---------' >>> `---------' >>> >>> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >>> >>> This document serves as the entry point to the set of ConEx >>> documentation, giving the 'why' rather than the 'how'. A companion >>> document outlines the ConEx protocol mechanism >>> [ConEx-Abstract-Mech]. >>> >>> The main aim of ConEx is to support evolution of alternatives to the >>> proliferation of traffic management solutions that are over- >>> constraining, non-transparent and often not application-neutral. >>> Traffic management ought to be able to leave end systems free to >>> choose how to behave without undue interference, while >>> simultaneously >>> satisfying the main concern of network operators; to control traffic >>> from some users that excessively limits the freedoms of others. >>> >>> Freedoms only actually collide when shared capacity becomes >>> congested--when a link is full so that a greater share for one user >>> would necessarily leave less for someone else. Current traffic >>> management solutions typically limit volume or bit-rate in order to >>> reduce the likelihood of congestion--limiting one thing in the hope >>> it might limit another. However, there is no real need to count >>> volume that is sent when there is no congestion, and there is no >>> real >>> need to limit bit-rate when there is no congestion. >>> >>> ConEx markings on packets add the missing information network >>> operators need to get a handle on congestion itself. Then they can >>> directly limit and control traffic based on how much it contributes >>> to congestion and leave traffic unconstrained if it doesn't cause >>> congestion. The idea is for the operator to be able to count and >>> control the bulk volume or bit-rate of packets marked for congestion >>> and disregard packets not contributing to congestion. >>> >>> With ConEx there is no need for the network provider to identify >>> specific applications or behaviours at the flow level, because the >>> relevant bulk congestion information is revealed at the network >>> layer. >> Better: IP layer? > > Done > > >>> Also, because ConEx information is added explicitly at the IP >>> layer, it is visible to provider and consumer alike. Therefore >>> traffic contracts or acceptable use policies can be based on a >>> metric >>> that is transparent to both parties and is sufficient to manage >>> traffic without extra non-transparent wriggle-room and caveats. >>> >>> In summary, ConEx is designed to make it simple to do traffic >>> management that is transparent, neutral and not over-constrained. >>> Although there is no implication that network operators ought to >>> provide such an unconstrained, transparent, neutral service, it >>> certainly should not be impossible and ideally it should be the >>> simplest service to provide. >> This sentence is a bit complicated. Can you simplify? > > I've edited it to: > Although there is no implication that network operators ought to > provide such an unconstrained, transparent, neutral service, it > certainly should not be impossible. Ideally it should also be the > simplest service to provide. > > > > >>> The IP layer is intended to engender new applications and behaviours >>> and to work over all existing and new lower layer technologies. >>> ConEx is a generative technology in this vein, with a range of >>> potential uses. This document focuses initially on traffic >>> management before widening out to introduce some additional >>> important >>> uses for ConEx as well as brifly mentioning a few others. >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >> I like this text about conex. However, I am not sure if one can fully >> follow if one doesn't have the "conex background". > > Would it be better if we explicitly permit the reader to not 'get it' > just by reading the Introduction. Also for the intro I prefer text that the user can understand quite well. Maybe parts of the content you want to bring in the intro would better fit into a conclusion? > > For example in para 2 we could add: > "The purpose of this doc is to ++outline the concepts necessary to > understand and++ motivate a new congestion exposure (ConEx) field at > the IP layer" > > And further down: > " The ++rather radical++ idea is for the operator to be able to count > and > control the bulk volume or bit-rate of packets marked for congestion "marked for congestion" is not clear Michael > and disregard packets not contributing to congestion." > > ? > > > Bob > > >> Regards, >> >> Michael >> >> >>> >>> >>> Bob Briscoe & Rich Woundy >>> >>> >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Tue Jun 14 13:50:50 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1660F21F8529 for ; Tue, 14 Jun 2011 13:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVv3WQ53NQUm for ; Tue, 14 Jun 2011 13:50:49 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 74BAA21F8528 for ; Tue, 14 Jun 2011 13:50:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 45CF952DA; Tue, 14 Jun 2011 22:50:45 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdbHnXIBsCi7; Tue, 14 Jun 2011 22:50:40 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id D009852BD; Tue, 14 Jun 2011 22:50:39 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id C6B831E00C87; Tue, 14 Jun 2011 22:50:37 +0200 (CEST) Message-ID: <4DF7C9A6.9000504@informatik.uni-tuebingen.de> Date: Tue, 14 Jun 2011 22:50:46 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> In-Reply-To: <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:50:50 -0000 Hi Bob, I tried to simplify parts of your text - which is now certainly not general enough anymore. But maybe it inspires you for the intro. Current traffic management solutions are not effective since they limit a user's traffic based on the wrong quantities. E.g. volume caps or rate limitations may not be strict enough in case of congestion while they unnecessarily constrain the freedom of end systems in the absence of congestion. Even worse, the methods may be not application-neutral and non-transparent [whatever transparent means ...]. Traffic management solutions could be so much better if they had congestion feedback from the network: access rates could be constrained when necessary and high bitrates could be allowed when possible. Congestion exposure (ConEx) aims to expose exactly that information to all IP nodes on a flow's path. Congestion information consists of packets that are lost or re-marked, e.g., by ECN-re-marking, so that it is complete only at the destination. Since this this is the quantity of interest, it needs to be feed back to the sender which encodes it in consecutive packets of the same flow. Thus, ConEx information reflects the conditions of the network of about one round-trip-time ago. To allow any IP node to access ConEx information, it must be coded in the IP header. Your intro often uses an opposite strategy: it first gives a definition/statement then it explains what it is good for. I prefer to say first what the problem is and then how we aim to solve it. I find that easier to understand. Best wishes, Michael Am 14.06.2011 20:03, schrieb Bob Briscoe: > Michael, > > Tx for the quick turn-round. > > Everything you suggest makes sense. I have pasted replacement paras in > the thread below to satisfy these requests. > > At 17:56 14/06/2011, Michael Menth wrote: >> Hi Bob, >> >> Am 14.06.2011 18:20, schrieb Bob Briscoe: >>> ConEx folks, >>> >>> After the last IETF in Prague, we agreed to work on a revised >>> draft-ietf-conex-concepts-uses. We're planning on using a lot of the >>> text as is, but we suggested that the Introduction needed a complete >>> re-write. Below is our joint proposal. >>> >>> Please bash. >>> >>> Rationale for this Introduction: >>> =============================== >>> * The main change is a shift to the main target use-case in the body >>> of the document: traffic management, leaving defining congestion etc >>> to the definitions and concepts section (section 2). >>> * Introduce enough of the solution to allow the reader to grasp the >>> main logic. >>> * Introduce one primary use and mention there are others - to keep >>> focused but hint at breadth. >>> * Start to weave in some benefits bullet points (transparency, >>> neutrality). >>> * Hint at controversies like the over-provisioning issue in the >>> first para, but leave addressing this to later, when we can go into >>> the subject properly. >>> >>> >>> >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>> 1. Introduction >> I think "IP layer" is more concrete >> I'd prefer if you integrate the Figure more into the text for >> describing Conex. This makes reading easier. > > 1st two paras again: > > The power of Internet technology comes from multiplexing shared > capacity with packets rather than circuits. Network operators > usually provide sufficient capacity, but whenever too much packet > load meets too little shared capacity, congestion results. > Congestion appears as either increased delay, missing packets or > packets explicitly marked with ECN [RFC3168]. The classic Internet > architecture is arranged so that receivers detect such signs of > congestion and feed them back end-to-end (shown at the middle and top > of Figure 1). Then, ideally, most senders reduce their rate in > response. > > The purpose of this document is to motivate a new congestion exposure > (ConEx) field at the IP layer. The idea is to add a third pass to > the feedback loop (shown at the bottom of Figure 1) so that the > sender can relay congestion information back into the IP layer, > exposing the level of congestion the sender expects packets to > experience along their whole path. Then certain network nodes can > use this new information at the IP layer, for example as input to > traffic management. > > >>> ,---------. >>> ,---------. >>> |Transport| >>> |Transport| >>> | Sender | >>> |Receiver | >>> | >>> |<==Feedback=Path==============================<| | >>> | ,---|<--Transport Layer returned Congestion >>> Signal-<|<--. | >>> | | | | >>> | | >>> | | | | >>> | | >>> | | | ,-----------. | >>> | | >>> | | | |(Congested)| | >>> | | >>> | | |>=Data=Path=>| Network |>=====Data=Path=====>| >>> | | >>> | | | | Device >>> |>-Congestion-Signal->|---' | >>> | | | `-----------' >>> | | >>> | `-->|>---------(new) IP layer ConEx >>> Signal--------->| | >>> | | (Carried in Data Packet Headers) >>> | | >>> `---------' >>> `---------' >>> >>> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >>> >>> This document serves as the entry point to the set of ConEx >>> documentation, giving the 'why' rather than the 'how'. A companion >>> document outlines the ConEx protocol mechanism >>> [ConEx-Abstract-Mech]. >>> >>> The main aim of ConEx is to support evolution of alternatives to the >>> proliferation of traffic management solutions that are over- >>> constraining, non-transparent and often not application-neutral. >>> Traffic management ought to be able to leave end systems free to >>> choose how to behave without undue interference, while >>> simultaneously >>> satisfying the main concern of network operators; to control traffic >>> from some users that excessively limits the freedoms of others. >>> >>> Freedoms only actually collide when shared capacity becomes >>> congested--when a link is full so that a greater share for one user >>> would necessarily leave less for someone else. Current traffic >>> management solutions typically limit volume or bit-rate in order to >>> reduce the likelihood of congestion--limiting one thing in the hope >>> it might limit another. However, there is no real need to count >>> volume that is sent when there is no congestion, and there is no >>> real >>> need to limit bit-rate when there is no congestion. >>> >>> ConEx markings on packets add the missing information network >>> operators need to get a handle on congestion itself. Then they can >>> directly limit and control traffic based on how much it contributes >>> to congestion and leave traffic unconstrained if it doesn't cause >>> congestion. The idea is for the operator to be able to count and >>> control the bulk volume or bit-rate of packets marked for congestion >>> and disregard packets not contributing to congestion. >>> >>> With ConEx there is no need for the network provider to identify >>> specific applications or behaviours at the flow level, because the >>> relevant bulk congestion information is revealed at the network >>> layer. >> Better: IP layer? > > Done > > >>> Also, because ConEx information is added explicitly at the IP >>> layer, it is visible to provider and consumer alike. Therefore >>> traffic contracts or acceptable use policies can be based on a >>> metric >>> that is transparent to both parties and is sufficient to manage >>> traffic without extra non-transparent wriggle-room and caveats. >>> >>> In summary, ConEx is designed to make it simple to do traffic >>> management that is transparent, neutral and not over-constrained. >>> Although there is no implication that network operators ought to >>> provide such an unconstrained, transparent, neutral service, it >>> certainly should not be impossible and ideally it should be the >>> simplest service to provide. >> This sentence is a bit complicated. Can you simplify? > > I've edited it to: > Although there is no implication that network operators ought to > provide such an unconstrained, transparent, neutral service, it > certainly should not be impossible. Ideally it should also be the > simplest service to provide. > > > > >>> The IP layer is intended to engender new applications and behaviours >>> and to work over all existing and new lower layer technologies. >>> ConEx is a generative technology in this vein, with a range of >>> potential uses. This document focuses initially on traffic >>> management before widening out to introduce some additional >>> important >>> uses for ConEx as well as brifly mentioning a few others. >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >> I like this text about conex. However, I am not sure if one can fully >> follow if one doesn't have the "conex background". > > Would it be better if we explicitly permit the reader to not 'get it' > just by reading the Introduction. > > For example in para 2 we could add: > "The purpose of this doc is to ++outline the concepts necessary to > understand and++ motivate a new congestion exposure (ConEx) field at > the IP layer" > > And further down: > " The ++rather radical++ idea is for the operator to be able to count > and > control the bulk volume or bit-rate of packets marked for congestion > and disregard packets not contributing to congestion." > > ? > > > Bob > > >> Regards, >> >> Michael >> >> >>> >>> >>> Bob Briscoe & Rich Woundy >>> >>> >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Jun 14 14:45:30 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5623D11E8168 for ; Tue, 14 Jun 2011 14:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXho0YVfp8Kt for ; Tue, 14 Jun 2011 14:45:29 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5430F11E80E8 for ; Tue, 14 Jun 2011 14:45:29 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 22:45:27 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 22:45:27 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 130808792619; Tue, 14 Jun 2011 22:45:26 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5ELjNHN028831; Tue, 14 Jun 2011 22:45:24 +0100 Message-Id: <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 22:45:23 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF7C02C.2020505@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> 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: 14 Jun 2011 21:45:27.0408 (UTC) FILETIME=[5FB9B700:01CC2ADC] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:45:30 -0000 Michael, At 21:10 14/06/2011, Michael Menth wrote: >Hi Bob, > >Am 14.06.2011 20:03, schrieb Bob Briscoe: >>Michael, >> >>Tx for the quick turn-round. >> >>Everything you suggest makes sense. I have pasted replacement paras >>in the thread below to satisfy these requests. >> >>At 17:56 14/06/2011, Michael Menth wrote: >>>Hi Bob, [snip] >>>I like this text about conex. However, I am not sure if one can >>>fully follow if one doesn't have the "conex background". >> >>Would it be better if we explicitly permit the reader to not 'get >>it' just by reading the Introduction. > >Also for the intro I prefer text that the user can understand quite well. Yes, I agree the reader must be able to understand everything they read in the order they read it. I meant that this is merely the introduction and the next section is about concepts and definitions, which is where understanding should really become more complete. > Maybe parts of the content you want to bring in the intro would > better fit into a conclusion? Please be more specific. Are you disagreeing with our Rationale for the introduction (repeated below), or are you saying we have written more than the rationale requires us to write? >>>>Rationale for this Introduction: >>>>=============================== >>>>* The main change is a shift to the main target use-case in the >>>>body of the document: traffic management, leaving defining >>>>congestion etc to the definitions and concepts section (section 2). >>>>* Introduce enough of the solution to allow the reader to grasp >>>>the main logic. >>>>* Introduce one primary use and mention there are others - to >>>>keep focused but hint at breadth. >>>>* Start to weave in some benefits bullet points (transparency, neutrality). >>>>* Hint at controversies like the over-provisioning issue in the >>>>first para, but leave addressing this to later, when we can go >>>>into the subject properly. >>For example in para 2 we could add: >>"The purpose of this doc is to ++outline the concepts necessary to >>understand and++ motivate a new congestion exposure (ConEx) field >>at the IP layer" >> >>And further down: >>" The ++rather radical++ idea is for the operator to be able to count and >> control the bulk volume or bit-rate of packets marked for congestion You haven't said whether these additions address what you were concerned about (if they don't I won't add them). >"marked for congestion" is not clear I've changed it to "...control the bulk volume or bit-rate of packets with ConEx markings..." (However, I originally avoided this because I was trying not to imply a particular mechanism). Bob >Michael > > >> and disregard packets not contributing to congestion." >> >>? >> >> >>Bob >> >> >>>Regards, >>> >>> Michael >>> >>> >>>> >>>> >>>>Bob Briscoe & Rich Woundy >>>> >>>> >>>> >>>>_______________________________________________ >>>>conex mailing list >>>>conex@ietf.org >>>>https://www.ietf.org/mailman/listinfo/conex >>> >>>-- ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Jun 14 14:49:58 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5A11E8174 for ; Tue, 14 Jun 2011 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-qxrVYvl456 for ; Tue, 14 Jun 2011 14:49:57 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4B11E808A for ; Tue, 14 Jun 2011 14:49:57 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 22:49:55 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 22:49:55 +0100 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 1308088194686; Tue, 14 Jun 2011 22:49:54 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5ELnp8M028850; Tue, 14 Jun 2011 22:49:52 +0100 Message-Id: <201106142149.p5ELnp8M028850@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 22:49:50 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF7BF43.1050104@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> <4DF7BF43.1050104@informatik.uni-tuebingen.de> 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: 14 Jun 2011 21:49:55.0440 (UTC) FILETIME=[FF7C2700:01CC2ADC] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:49:58 -0000 Michael, At 21:06 14/06/2011, Michael Menth wrote: >Hi Bob, > >Am 14.06.2011 20:55, schrieb Bob Briscoe: >>Steve, >> >>I see the problem - we tried to link back to the first mention of >>the word 'free', but the text could be misconstrued to mean freedom >>of information, freedom of speech, freedom of association etc, not >>just freedom at the traffic behaviour level. >> >>How about: >>" Traffic management ought to be able to leave end systems free to >> choose how to behave without undue interference, while simultaneously >> satisfying the main concern of network operators; to control traffic >> from some users that excessively limits the freedom of others to send >> how they want. >> >> These freedoms only actually collide when shared capacity becomes >> congested... >>" >I understand this paragraph only as I am in the meantime used to >this special wording that is relatively far from technical. > >Problems to catch the meaning can be: "without undue interference" >is not necessarily clear what it means. Also the story with >"freedom" and "freedoms collide" is quite metaphoric. I know now >what this means, but it's not so easy for newbies. Perhaps you are taking the above out of context, because I didn't repeat the following text, which I think moves from abstract general freedom to more concrete freedom to do x and y. " These freedoms only actually collide when shared capacity becomes congested--when a link is full so that a greater share for one user would necessarily leave less for someone else. Current traffic management solutions typically limit volume or bit-rate in order to reduce the likelihood of congestion--limiting one thing in the hope it might limit another. However, there is no real need to count volume that is sent when there is no congestion, and there is no real need to limit bit-rate when there is no congestion. " Bob >Regards, > > Michael > > > > >> >> >> >>Bob >> >>At 19:33 14/06/2011, Steve Bauer wrote: >>> > Traffic management ought to be able to leave end systems free to >>> > choose how to behave without undue interference, while simultaneously >>> > satisfying the main concern of network operators; to control traffic >>> > from some users that excessively limits the freedoms of others. >>> > >>> > Freedoms only actually collide when shared capacity becomes >>> > congested--when a link is full so that a greater share for one user >>> > would necessarily leave less for someone else. >>> >>>One part that caused me to wince was the discussion of "freedoms". I >>>don't want to equate congesting a link with stomping on other's >>>liberty. You must mean this in a technical sense, so I would use >>>language that is less loaded. >>> >>>Or maybe you deliberately choose "freedom" here? I do understand that >>>these paragraphs are getting to the core of the motivation... >>> >>>I would have perhaps said "the main concern of network operators" was >>>"to control traffic from some users that disproportionately cause >>>congestion." And then maybe just strike the first sentence of the >>>following paragraph which also discusses "freedoms". >>> >>>-Steve >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Jun 14 14:58:09 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1F811E808A for ; Tue, 14 Jun 2011 14:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWxVsBXZNrRb for ; Tue, 14 Jun 2011 14:58:08 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id CE18C11E8086 for ; Tue, 14 Jun 2011 14:58:05 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 22:58:04 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Jun 2011 22:58:04 +0100 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 1308088683858; Tue, 14 Jun 2011 22:58:03 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.47]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5ELw00H028898; Tue, 14 Jun 2011 22:58:00 +0100 Message-Id: <201106142158.p5ELw00H028898@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 22:58:00 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF7C9A6.9000504@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C9A6.9000504@informatik.uni-tuebingen.de> 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: 14 Jun 2011 21:58:04.0399 (UTC) FILETIME=[22ED5FF0:01CC2ADE] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:58:09 -0000 Michael, Yes, these two paras are better. There are some new problems, but I will try to work on them. I am imagining the Intro still starts the same as proposed, and this text only starts after the 3rd para, replacing: " The main aim of ConEx is to support evolution of alternatives to the proliferation of traffic management solutions that are over- constraining, non-transparent and often not application-neutral... etc " Or are you thinking your text starts the Introduction? Bob At 21:50 14/06/2011, Michael Menth wrote: >Hi Bob, > >I tried to simplify parts of your text - which is now certainly not >general enough anymore. But maybe it inspires you for the intro. > >Current traffic management solutions are not effective since they limit a >user's traffic based on the wrong quantities. E.g. volume caps or rate >limitations may not be strict enough in case of congestion while they >unnecessarily constrain the freedom of end systems in the absence of >congestion. Even worse, the methods may be not application-neutral and >non-transparent [whatever transparent means ...]. > >Traffic management solutions could be so much better if they had congestion >feedback from the network: access rates could be constrained when necessary >and high bitrates could be allowed when possible. Congestion exposure (ConEx) >aims to expose exactly that information to all IP nodes on a flow's path. >Congestion information consists of packets that are lost or re-marked, e.g., >by ECN-re-marking, so that it is complete only at the destination. Since this >this is the quantity of interest, it needs to be feed back to the sender >which encodes it in consecutive packets of the same flow. Thus, ConEx >information reflects the conditions of the network of about one >round-trip-time ago. To allow any IP node to access ConEx information, it >must be coded in the IP header. > >Your intro often uses an opposite strategy: it first gives a >definition/statement then it explains what it is good for. I prefer >to say first what the problem is and then how we aim to solve it. I >find that easier to understand. > >Best wishes, > > Michael > > >Am 14.06.2011 20:03, schrieb Bob Briscoe: >>Michael, >> >>Tx for the quick turn-round. >> >>Everything you suggest makes sense. I have pasted replacement paras >>in the thread below to satisfy these requests. >> >>At 17:56 14/06/2011, Michael Menth wrote: >>>Hi Bob, >>> >>>Am 14.06.2011 18:20, schrieb Bob Briscoe: >>>>ConEx folks, >>>> >>>>After the last IETF in Prague, we agreed to work on a revised >>>>draft-ietf-conex-concepts-uses. We're planning on using a lot of >>>>the text as is, but we suggested that the Introduction needed a >>>>complete re-write. Below is our joint proposal. >>>> >>>>Please bash. >>>> >>>>Rationale for this Introduction: >>>>=============================== >>>>* The main change is a shift to the main target use-case in the >>>>body of the document: traffic management, leaving defining >>>>congestion etc to the definitions and concepts section (section 2). >>>>* Introduce enough of the solution to allow the reader to grasp >>>>the main logic. >>>>* Introduce one primary use and mention there are others - to >>>>keep focused but hint at breadth. >>>>* Start to weave in some benefits bullet points (transparency, neutrality). >>>>* Hint at controversies like the over-provisioning issue in the >>>>first para, but leave addressing this to later, when we can go >>>>into the subject properly. >>>> >>>> >>>> >>>>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>>>1. Introduction >>>I think "IP layer" is more concrete >>>I'd prefer if you integrate the Figure more into the text for >>>describing Conex. This makes reading easier. >> >>1st two paras again: >> >> The power of Internet technology comes from multiplexing shared >> capacity with packets rather than circuits. Network operators >> usually provide sufficient capacity, but whenever too much packet >> load meets too little shared capacity, congestion results. >> Congestion appears as either increased delay, missing packets or >> packets explicitly marked with ECN [RFC3168]. The classic Internet >> architecture is arranged so that receivers detect such signs of >> congestion and feed them back end-to-end (shown at the middle and top >> of Figure 1). Then, ideally, most senders reduce their rate in >> response. >> >> The purpose of this document is to motivate a new congestion exposure >> (ConEx) field at the IP layer. The idea is to add a third pass to >> the feedback loop (shown at the bottom of Figure 1) so that the >> sender can relay congestion information back into the IP layer, >> exposing the level of congestion the sender expects packets to >> experience along their whole path. Then certain network nodes can >> use this new information at the IP layer, for example as input to >> traffic management. >> >> >>>> ,---------. >>>>,---------. >>>> |Transport| >>>>|Transport| >>>> | Sender | >>>>|Receiver | >>>> | >>>>|<==Feedback=Path==============================<| | >>>> | ,---|<--Transport Layer returned Congestion Signal-<|<--. | >>>> | | | | >>>>| | >>>> | | | | >>>>| | >>>> | | | ,-----------. | >>>>| | >>>> | | | |(Congested)| | >>>>| | >>>> | | |>=Data=Path=>| Network |>=====Data=Path=====>| >>>>| | >>>> | | | | Device >>>>|>-Congestion-Signal->|---' | >>>> | | | `-----------' >>>>| | >>>> | `-->|>---------(new) IP layer ConEx Signal--------->| | >>>> | | (Carried in Data Packet Headers) >>>>| | >>>> `---------' >>>>`---------' >>>> >>>> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >>>> >>>> This document serves as the entry point to the set of ConEx >>>> documentation, giving the 'why' rather than the 'how'. A companion >>>> document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. >>>> >>>> The main aim of ConEx is to support evolution of alternatives to the >>>> proliferation of traffic management solutions that are over- >>>> constraining, non-transparent and often not application-neutral. >>>> Traffic management ought to be able to leave end systems free to >>>> choose how to behave without undue interference, while simultaneously >>>> satisfying the main concern of network operators; to control traffic >>>> from some users that excessively limits the freedoms of others. >>>> >>>> Freedoms only actually collide when shared capacity becomes >>>> congested--when a link is full so that a greater share for one user >>>> would necessarily leave less for someone else. Current traffic >>>> management solutions typically limit volume or bit-rate in order to >>>> reduce the likelihood of congestion--limiting one thing in the hope >>>> it might limit another. However, there is no real need to count >>>> volume that is sent when there is no congestion, and there is no real >>>> need to limit bit-rate when there is no congestion. >>>> >>>> ConEx markings on packets add the missing information network >>>> operators need to get a handle on congestion itself. Then they can >>>> directly limit and control traffic based on how much it contributes >>>> to congestion and leave traffic unconstrained if it doesn't cause >>>> congestion. The idea is for the operator to be able to count and >>>> control the bulk volume or bit-rate of packets marked for congestion >>>> and disregard packets not contributing to congestion. >>>> >>>> With ConEx there is no need for the network provider to identify >>>> specific applications or behaviours at the flow level, because the >>>> relevant bulk congestion information is revealed at the network >>>> layer. >>>Better: IP layer? >> >>Done >> >> >>>>Also, because ConEx information is added explicitly at the IP >>>> layer, it is visible to provider and consumer alike. Therefore >>>> traffic contracts or acceptable use policies can be based on a metric >>>> that is transparent to both parties and is sufficient to manage >>>> traffic without extra non-transparent wriggle-room and caveats. >>>> >>>> In summary, ConEx is designed to make it simple to do traffic >>>> management that is transparent, neutral and not over-constrained. >>>> Although there is no implication that network operators ought to >>>> provide such an unconstrained, transparent, neutral service, it >>>> certainly should not be impossible and ideally it should be the >>>> simplest service to provide. >>>This sentence is a bit complicated. Can you simplify? >> >>I've edited it to: >> Although there is no implication that network operators ought to >> provide such an unconstrained, transparent, neutral service, it >> certainly should not be impossible. Ideally it should also be the >> simplest service to provide. >> >> >> >> >>>> The IP layer is intended to engender new applications and behaviours >>>> and to work over all existing and new lower layer technologies. >>>> ConEx is a generative technology in this vein, with a range of >>>> potential uses. This document focuses initially on traffic >>>> management before widening out to introduce some additional important >>>> uses for ConEx as well as brifly mentioning a few others. >>>>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>> >>>I like this text about conex. However, I am not sure if one can >>>fully follow if one doesn't have the "conex background". >> >>Would it be better if we explicitly permit the reader to not 'get >>it' just by reading the Introduction. >> >>For example in para 2 we could add: >>"The purpose of this doc is to ++outline the concepts necessary to >>understand and++ motivate a new congestion exposure (ConEx) field >>at the IP layer" >> >>And further down: >>" The ++rather radical++ idea is for the operator to be able to count and >> control the bulk volume or bit-rate of packets marked for congestion >> and disregard packets not contributing to congestion." >> >>? >> >> >>Bob >> >> >>>Regards, >>> >>> Michael >>> >>> >>>> >>>> >>>>Bob Briscoe & Rich Woundy >>>> >>>> >>>> >>>>_______________________________________________ >>>>conex mailing list >>>>conex@ietf.org >>>>https://www.ietf.org/mailman/listinfo/conex >>> >>>-- >>>Prof. Dr. habil. Michael Menth >>>University of Tuebingen >>>Faculty of Science >>>Department of Computer Science >>>Chair of Communication Networks >>>Sand 13, 72076 Tuebingen, Germany >>>phone: (+49)-7071/29-70505 >>>fax: (+49)-7071/29-5220 >>>mailto:menth@uni-tuebingen.de >>>http://www-kn.informatik.uni-tuebingen.de >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Tue Jun 14 22:58:39 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BA111E808C for ; Tue, 14 Jun 2011 22:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkKyHxUSWE3J for ; Tue, 14 Jun 2011 22:58:38 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id C842B11E80A1 for ; Tue, 14 Jun 2011 22:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id AF4E852D9; Wed, 15 Jun 2011 07:58:32 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8Fea9KCOiLn; Wed, 15 Jun 2011 07:58:28 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id CFF2A52AB; Wed, 15 Jun 2011 07:58:27 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3D04D117E11F; Wed, 15 Jun 2011 07:58:27 +0200 (CEST) Message-ID: <4DF84A12.7040405@informatik.uni-tuebingen.de> Date: Wed, 15 Jun 2011 07:58:42 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> <4DF7BF43.1050104@informatik.uni-tuebingen.de> <201106142149.p5ELnp8M028850@bagheera.jungle.bt.co.uk> In-Reply-To: <201106142149.p5ELnp8M028850@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 05:58:39 -0000 Hi Bob, Am 14.06.2011 23:49, schrieb Bob Briscoe: > Michael, > > At 21:06 14/06/2011, Michael Menth wrote: >> Hi Bob, >> >> Am 14.06.2011 20:55, schrieb Bob Briscoe: >>> Steve, >>> >>> I see the problem - we tried to link back to the first mention of >>> the word 'free', but the text could be misconstrued to mean freedom >>> of information, freedom of speech, freedom of association etc, not >>> just freedom at the traffic behaviour level. >>> >>> How about: >>> " Traffic management ought to be able to leave end systems free to >>> choose how to behave without undue interference, while >>> simultaneously >>> satisfying the main concern of network operators; to control traffic >>> from some users that excessively limits the freedom of others to >>> send >>> how they want. >>> >>> These freedoms only actually collide when shared capacity becomes >>> congested... >>> " >> I understand this paragraph only as I am in the meantime used to this >> special wording that is relatively far from technical. >> >> Problems to catch the meaning can be: "without undue interference" is >> not necessarily clear what it means. Also the story with "freedom" >> and "freedoms collide" is quite metaphoric. I know now what this >> means, but it's not so easy for newbies. > > Perhaps you are taking the above out of context, because I didn't > repeat the following text, which I think moves from abstract general > freedom to more concrete freedom to do x and y. > > " These freedoms only actually collide when shared capacity becomes > congested--when a link is full so that a greater share for one user > would necessarily leave less for someone else. Current traffic > management solutions typically limit volume or bit-rate in order to > reduce the likelihood of congestion--limiting one thing in the hope > it might limit another. in order to ... -> in the hope it reduces the likelihood of congestion. > However, there is no real need to count > volume that is sent when there is no congestion, and there is no real > need to limit bit-rate when there is no congestion. > " Newbies need to know that "freedom" is basically the traffic profile allowed by an ISP. Or even something more complicated. This text possibly defines that implicitly by using the word freedom in this context, but it does not define it clearly enough. Michael > > > Bob > > >> Regards, >> >> Michael >> >> >> >> >>> >>> >>> >>> Bob >>> >>> At 19:33 14/06/2011, Steve Bauer wrote: >>>> > Traffic management ought to be able to leave end systems free to >>>> > choose how to behave without undue interference, while >>>> simultaneously >>>> > satisfying the main concern of network operators; to control >>>> traffic >>>> > from some users that excessively limits the freedoms of others. >>>> > >>>> > Freedoms only actually collide when shared capacity becomes >>>> > congested--when a link is full so that a greater share for one >>>> user >>>> > would necessarily leave less for someone else. >>>> >>>> One part that caused me to wince was the discussion of "freedoms". I >>>> don't want to equate congesting a link with stomping on other's >>>> liberty. You must mean this in a technical sense, so I would use >>>> language that is less loaded. >>>> >>>> Or maybe you deliberately choose "freedom" here? I do understand that >>>> these paragraphs are getting to the core of the motivation... >>>> >>>> I would have perhaps said "the main concern of network operators" was >>>> "to control traffic from some users that disproportionately cause >>>> congestion." And then maybe just strike the first sentence of the >>>> following paragraph which also discusses "freedoms". >>>> >>>> -Steve >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Tue Jun 14 22:58:39 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02511E80A1 for ; Tue, 14 Jun 2011 22:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPDVI+mbmORM for ; Tue, 14 Jun 2011 22:58:38 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id C84BB11E80D6 for ; Tue, 14 Jun 2011 22:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9924252AB; Wed, 15 Jun 2011 07:58:34 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v4rXjWzgp01; Wed, 15 Jun 2011 07:58:29 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id A2D9F52D2; Wed, 15 Jun 2011 07:58:29 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id DFF3D117E120; Wed, 15 Jun 2011 07:58:29 +0200 (CEST) Message-ID: <4DF84A16.1000805@informatik.uni-tuebingen.de> Date: Wed, 15 Jun 2011 07:58:46 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C9A6.9000504@informatik.uni-tuebingen.de> <201106142158.p5ELw00H028898@bagheera.jungle.bt.co.uk> In-Reply-To: <201106142158.p5ELw00H028898@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 05:58:39 -0000 Hi Bob, Am 14.06.2011 23:58, schrieb Bob Briscoe: > Michael, > > Yes, these two paras are better. There are some new problems, but I > will try to work on them. > > I am imagining the Intro still starts the same as proposed, and this > text only starts after the 3rd para, replacing: > > " The main aim of ConEx is to support evolution of alternatives to the > proliferation of traffic management solutions that are over- > constraining, non-transparent and often not application-neutral... > etc > " > > Or are you thinking your text starts the Introduction? No Michael > > > Bob > > At 21:50 14/06/2011, Michael Menth wrote: >> Hi Bob, >> >> I tried to simplify parts of your text - which is now certainly not >> general enough anymore. But maybe it inspires you for the intro. >> >> Current traffic management solutions are not effective since they >> limit a >> user's traffic based on the wrong quantities. E.g. volume caps or rate >> limitations may not be strict enough in case of congestion while they >> unnecessarily constrain the freedom of end systems in the absence of >> congestion. Even worse, the methods may be not application-neutral and >> non-transparent [whatever transparent means ...]. >> >> Traffic management solutions could be so much better if they had >> congestion >> feedback from the network: access rates could be constrained when >> necessary >> and high bitrates could be allowed when possible. Congestion exposure >> (ConEx) >> aims to expose exactly that information to all IP nodes on a flow's >> path. >> Congestion information consists of packets that are lost or >> re-marked, e.g., >> by ECN-re-marking, so that it is complete only at the destination. >> Since this >> this is the quantity of interest, it needs to be feed back to the sender >> which encodes it in consecutive packets of the same flow. Thus, ConEx >> information reflects the conditions of the network of about one >> round-trip-time ago. To allow any IP node to access ConEx >> information, it >> must be coded in the IP header. >> >> Your intro often uses an opposite strategy: it first gives a >> definition/statement then it explains what it is good for. I prefer >> to say first what the problem is and then how we aim to solve it. I >> find that easier to understand. >> >> Best wishes, >> >> Michael >> >> >> Am 14.06.2011 20:03, schrieb Bob Briscoe: >>> Michael, >>> >>> Tx for the quick turn-round. >>> >>> Everything you suggest makes sense. I have pasted replacement paras >>> in the thread below to satisfy these requests. >>> >>> At 17:56 14/06/2011, Michael Menth wrote: >>>> Hi Bob, >>>> >>>> Am 14.06.2011 18:20, schrieb Bob Briscoe: >>>>> ConEx folks, >>>>> >>>>> After the last IETF in Prague, we agreed to work on a revised >>>>> draft-ietf-conex-concepts-uses. We're planning on using a lot of >>>>> the text as is, but we suggested that the Introduction needed a >>>>> complete re-write. Below is our joint proposal. >>>>> >>>>> Please bash. >>>>> >>>>> Rationale for this Introduction: >>>>> =============================== >>>>> * The main change is a shift to the main target use-case in the >>>>> body of the document: traffic management, leaving defining >>>>> congestion etc to the definitions and concepts section (section 2). >>>>> * Introduce enough of the solution to allow the reader to grasp >>>>> the main logic. >>>>> * Introduce one primary use and mention there are others - to keep >>>>> focused but hint at breadth. >>>>> * Start to weave in some benefits bullet points (transparency, >>>>> neutrality). >>>>> * Hint at controversies like the over-provisioning issue in the >>>>> first para, but leave addressing this to later, when we can go >>>>> into the subject properly. >>>>> >>>>> >>>>> >>>>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>>>> >>>>> 1. Introduction >>>> I think "IP layer" is more concrete >>>> I'd prefer if you integrate the Figure more into the text for >>>> describing Conex. This makes reading easier. >>> >>> 1st two paras again: >>> >>> The power of Internet technology comes from multiplexing shared >>> capacity with packets rather than circuits. Network operators >>> usually provide sufficient capacity, but whenever too much packet >>> load meets too little shared capacity, congestion results. >>> Congestion appears as either increased delay, missing packets or >>> packets explicitly marked with ECN [RFC3168]. The classic Internet >>> architecture is arranged so that receivers detect such signs of >>> congestion and feed them back end-to-end (shown at the middle and >>> top >>> of Figure 1). Then, ideally, most senders reduce their rate in >>> response. >>> >>> The purpose of this document is to motivate a new congestion >>> exposure >>> (ConEx) field at the IP layer. The idea is to add a third pass to >>> the feedback loop (shown at the bottom of Figure 1) so that the >>> sender can relay congestion information back into the IP layer, >>> exposing the level of congestion the sender expects packets to >>> experience along their whole path. Then certain network nodes can >>> use this new information at the IP layer, for example as input to >>> traffic management. >>> >>> >>>>> ,---------. >>>>> ,---------. >>>>> |Transport| >>>>> |Transport| >>>>> | Sender | >>>>> |Receiver | >>>>> | >>>>> |<==Feedback=Path==============================<| | >>>>> | ,---|<--Transport Layer returned Congestion >>>>> Signal-<|<--. | >>>>> | | | | >>>>> | | >>>>> | | | | >>>>> | | >>>>> | | | ,-----------. | >>>>> | | >>>>> | | | |(Congested)| | >>>>> | | >>>>> | | |>=Data=Path=>| Network |>=====Data=Path=====>| >>>>> | | >>>>> | | | | Device >>>>> |>-Congestion-Signal->|---' | >>>>> | | | `-----------' >>>>> | | >>>>> | `-->|>---------(new) IP layer ConEx >>>>> Signal--------->| | >>>>> | | (Carried in Data Packet Headers) >>>>> | | >>>>> `---------' >>>>> `---------' >>>>> >>>>> Figure 1: Where the ConEx Protocol Fits in the Internet >>>>> Architecture >>>>> >>>>> This document serves as the entry point to the set of ConEx >>>>> documentation, giving the 'why' rather than the 'how'. A >>>>> companion >>>>> document outlines the ConEx protocol mechanism >>>>> [ConEx-Abstract-Mech]. >>>>> >>>>> The main aim of ConEx is to support evolution of alternatives >>>>> to the >>>>> proliferation of traffic management solutions that are over- >>>>> constraining, non-transparent and often not application-neutral. >>>>> Traffic management ought to be able to leave end systems free to >>>>> choose how to behave without undue interference, while >>>>> simultaneously >>>>> satisfying the main concern of network operators; to control >>>>> traffic >>>>> from some users that excessively limits the freedoms of others. >>>>> >>>>> Freedoms only actually collide when shared capacity becomes >>>>> congested--when a link is full so that a greater share for one >>>>> user >>>>> would necessarily leave less for someone else. Current traffic >>>>> management solutions typically limit volume or bit-rate in >>>>> order to >>>>> reduce the likelihood of congestion--limiting one thing in the >>>>> hope >>>>> it might limit another. However, there is no real need to count >>>>> volume that is sent when there is no congestion, and there is >>>>> no real >>>>> need to limit bit-rate when there is no congestion. >>>>> >>>>> ConEx markings on packets add the missing information network >>>>> operators need to get a handle on congestion itself. Then they >>>>> can >>>>> directly limit and control traffic based on how much it >>>>> contributes >>>>> to congestion and leave traffic unconstrained if it doesn't cause >>>>> congestion. The idea is for the operator to be able to count and >>>>> control the bulk volume or bit-rate of packets marked for >>>>> congestion >>>>> and disregard packets not contributing to congestion. >>>>> >>>>> With ConEx there is no need for the network provider to identify >>>>> specific applications or behaviours at the flow level, because the >>>>> relevant bulk congestion information is revealed at the network >>>>> layer. >>>> Better: IP layer? >>> >>> Done >>> >>> >>>>> Also, because ConEx information is added explicitly at the IP >>>>> layer, it is visible to provider and consumer alike. Therefore >>>>> traffic contracts or acceptable use policies can be based on a >>>>> metric >>>>> that is transparent to both parties and is sufficient to manage >>>>> traffic without extra non-transparent wriggle-room and caveats. >>>>> >>>>> In summary, ConEx is designed to make it simple to do traffic >>>>> management that is transparent, neutral and not over-constrained. >>>>> Although there is no implication that network operators ought to >>>>> provide such an unconstrained, transparent, neutral service, it >>>>> certainly should not be impossible and ideally it should be the >>>>> simplest service to provide. >>>> This sentence is a bit complicated. Can you simplify? >>> >>> I've edited it to: >>> Although there is no implication that network operators ought to >>> provide such an unconstrained, transparent, neutral service, it >>> certainly should not be impossible. Ideally it should also be the >>> simplest service to provide. >>> >>> >>> >>> >>>>> The IP layer is intended to engender new applications and >>>>> behaviours >>>>> and to work over all existing and new lower layer technologies. >>>>> ConEx is a generative technology in this vein, with a range of >>>>> potential uses. This document focuses initially on traffic >>>>> management before widening out to introduce some additional >>>>> important >>>>> uses for ConEx as well as brifly mentioning a few others. >>>>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>>>> >>>> >>>> I like this text about conex. However, I am not sure if one can >>>> fully follow if one doesn't have the "conex background". >>> >>> Would it be better if we explicitly permit the reader to not 'get >>> it' just by reading the Introduction. >>> >>> For example in para 2 we could add: >>> "The purpose of this doc is to ++outline the concepts necessary to >>> understand and++ motivate a new congestion exposure (ConEx) field at >>> the IP layer" >>> >>> And further down: >>> " The ++rather radical++ idea is for the operator to be able to >>> count and >>> control the bulk volume or bit-rate of packets marked for congestion >>> and disregard packets not contributing to congestion." >>> >>> ? >>> >>> >>> Bob >>> >>> >>>> Regards, >>>> >>>> Michael >>>> >>>> >>>>> >>>>> >>>>> Bob Briscoe & Rich Woundy >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> conex mailing list >>>>> conex@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/conex >>>> >>>> -- >>>> Prof. Dr. habil. Michael Menth >>>> University of Tuebingen >>>> Faculty of Science >>>> Department of Computer Science >>>> Chair of Communication Networks >>>> Sand 13, 72076 Tuebingen, Germany >>>> phone: (+49)-7071/29-70505 >>>> fax: (+49)-7071/29-5220 >>>> mailto:menth@uni-tuebingen.de >>>> http://www-kn.informatik.uni-tuebingen.de >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >> >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Tue Jun 14 23:17:13 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F211E8076 for ; Tue, 14 Jun 2011 23:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqaZ6GxonsDD for ; Tue, 14 Jun 2011 23:17:13 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 95ADC11E8096 for ; Tue, 14 Jun 2011 23:17:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1284052D9; Wed, 15 Jun 2011 07:58:42 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMMm0P-xqsfK; Wed, 15 Jun 2011 07:58:38 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id AF15752AB; Wed, 15 Jun 2011 07:58:38 +0200 (MEST) Received: from [192.168.1.100] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id B124A117E124; Wed, 15 Jun 2011 07:58:38 +0200 (CEST) Message-ID: <4DF84A1E.5050907@informatik.uni-tuebingen.de> Date: Wed, 15 Jun 2011 07:58:54 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> In-Reply-To: <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 06:17:13 -0000 Hi Bob, Am 14.06.2011 23:45, schrieb Bob Briscoe: > Michael, > > At 21:10 14/06/2011, Michael Menth wrote: >> Hi Bob, >> >> Am 14.06.2011 20:03, schrieb Bob Briscoe: >>> Michael, >>> >>> Tx for the quick turn-round. >>> >>> Everything you suggest makes sense. I have pasted replacement paras >>> in the thread below to satisfy these requests. >>> >>> At 17:56 14/06/2011, Michael Menth wrote: >>>> Hi Bob, > > [snip] > >>>> I like this text about conex. However, I am not sure if one can >>>> fully follow if one doesn't have the "conex background". >>> >>> Would it be better if we explicitly permit the reader to not 'get >>> it' just by reading the Introduction. >> >> Also for the intro I prefer text that the user can understand quite >> well. > > Yes, I agree the reader must be able to understand everything they > read in the order they read it. I meant that this is merely the > introduction and the next section is about concepts and definitions, > which is where understanding should really become more complete. > >> Maybe parts of the content you want to bring in the intro would >> better fit into a conclusion? > > Please be more specific. Are you disagreeing with our Rationale for > the introduction (repeated below), or are you saying we have written > more than the rationale requires us to write? One can say here is the problem and that's the solution. Or one can say: that's a new mechanism which could solve that problem. For me the first approach is simpler, but your outline is of course also doable. I believe that the major challenge for a newbie in the text is the set of used metaphoras and implicit definitions/formulations which are partly quite dense in the sense that they are almost conclusions. That was an obstacle for me in the very beginning of ConEx. Being more explicit facilitates reading. > > >>>>> Rationale for this Introduction: >>>>> =============================== >>>>> * The main change is a shift to the main target use-case in the >>>>> body of the document: traffic management, leaving defining >>>>> congestion etc to the definitions and concepts section (section 2). I'm not quite sure what you mean by that. Probably "change" with respect to the existing draft, right? >>>>> * Introduce enough of the solution to allow the reader to grasp >>>>> the main logic. >>>>> * Introduce one primary use and mention there are others - to keep >>>>> focused but hint at breadth. >>>>> * Start to weave in some benefits bullet points (transparency, >>>>> neutrality). I am not sure what you mean by transparancy. Also neutrality could be briefly explained in this context. >>>>> * Hint at controversies like the over-provisioning issue in the >>>>> first para, but leave addressing this to later, when we can go >>>>> into the subject properly. > > > >>> For example in para 2 we could add: >>> "The purpose of this doc is to ++outline the concepts necessary to >>> understand and++ motivate a new congestion exposure (ConEx) field at >>> the IP layer" The purpose of this doc is to point out current problems in traffic manament that are due to deficiencies of today's Internet architecture. We argue that a new congestion exposure (ConEx) field at the IP layer could provide valuable information for innovative solutions to that problem. >>> >>> And further down: >>> " The ++rather radical++ idea is for the operator to be able to >>> count and >>> control the bulk volume or bit-rate of packets marked for congestion > > You haven't said whether these additions address what you were > concerned about (if they don't I won't add them). My concern was more that the text is excellent for people who are used to ConEx language but it may be difficult to read for others. > >> "marked for congestion" is not clear > > I've changed it to > "...control the bulk volume or bit-rate of packets with ConEx > markings..." > > (However, I originally avoided this because I was trying not to imply > a particular mechanism). This formulation probably avoids the particular mechanism and points out the difference to existing solutions: The rather radical idea is for the operator to be able to do traffic manament based on congestion feedback from the network. While existing mechanisms provide such information only to the source of a flow, ConEx makes it accessible to each node on a path. Michael > > > Bob > > >> Michael >> >> >>> and disregard packets not contributing to congestion." >>> >>> ? >>> >>> >>> Bob >>> >>> >>>> Regards, >>>> >>>> Michael >>>> >>>> >>>>> >>>>> >>>>> Bob Briscoe & Rich Woundy >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> conex mailing list >>>>> conex@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/conex >>>> >>>> -- > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From dave.mcdysan@verizon.com Wed Jun 15 06:15:13 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7433011E80FC for ; Wed, 15 Jun 2011 06:15:13 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVGe8VzhOak5 for ; Wed, 15 Jun 2011 06:15:12 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6767511E80EF for ; Wed, 15 Jun 2011 06:15:12 -0700 (PDT) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p5FDEu0D013306 for ; Wed, 15 Jun 2011 09:15:09 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="72687572" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 15 Jun 2011 13:13:51 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.164]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 15 Jun 2011 09:13:51 -0400 To: ConEx IETF list Date: Wed, 15 Jun 2011 09:13:50 -0400 Thread-Topic: [conex] draft-ietf-conex-concepts-uses: New Intro text Thread-Index: AcwrXhFQTOzUYBVeStmNXRr0XCeGsA== Message-ID: In-Reply-To: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> 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 Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:15:13 -0000 Bob, Rich, This is an improved introduction. The ASCII art illustrating the nesting of control systems derived from the Mathis/Briscoe presentations on the mechanism draft is most helpful in communicating the overall context and structure of the mechanism, and I assume that a version of this figure will also be placed in the mechanism draft. IMO, the introduction needs to explain at a high-level at least one major benefit that will be seen by operators and end users. I would like to be able to give the use case document to someone who is not familiar with conex at all and they should be able to get this message from reading the introduction alone. (They may not know from the introduction how these benefits are achieved, but the summary of benefit(s) in the introduction should be compelling enough to motivate the reader to continue reading more of the document.) Scanning over other responses in the thread, I believe that Michael Menth has made a similar comment. I include some text for discussion in line below summarizing these benefits for discussion by the working group. Also, I think at some point in the document, the timescales over which this third pass of the control loop operates and the high-level net effect of congestion encoding needs to be described. I suggest at least inserting the word "persistent" Finally, the introduction mentions shared congestion, but at some point the document needs to address the case when a single user is causing congestion of a non-shared queue (e.g., a DSL/cable modem). Thanks, Dave On Tuesday6/14/11 12:20 PM, "Bob Briscoe" wrote: >ConEx folks, > >After the last IETF in Prague, we agreed to work on a revised >draft-ietf-conex-concepts-uses. We're planning on using a lot of the >text as is, but we suggested that the Introduction needed a complete >re-write. Below is our joint proposal. > >Please bash. > >Rationale for this Introduction: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >* The main change is a shift to the main target use-case in the body >of the document: traffic management, leaving defining congestion etc >to the definitions and concepts section (section 2). >* Introduce enough of the solution to allow the reader to grasp the main >logic. >* Introduce one primary use and mention there are others - to keep >focused but hint at breadth. >* Start to weave in some benefits bullet points (transparency, >neutrality). >* Hint at controversies like the over-provisioning issue in the first >para, but leave addressing this to later, when we can go into the >subject properly. > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >1. Introduction > > The power of Internet technology comes from multiplexing shared > capacity with packets rather than circuits. Network operators > usually provide sufficient capacity, but whenever too much packet > load meets too little shared capacity, congestion results. > Congestion appears as either increased delay, missing packets or > packets explicitly marked with ECN [RFC3168]. The classic Internet > architecture is arranged so that receivers detect such signs of > congestion and feed them back end-to-end. Then, ideally, most > senders reduce their rate in response. > > The purpose of this document is to motivate a new congestion exposure > (ConEx) field at the IP layer. The idea is to add a third pass to > the feedback loop so that the sender can relay congestion information > back into the internetwork layer, exposing the level of congestion > the sender expects packets to experience along their whole path > (Figure 1). Then certain network nodes can use this new information > at the IP layer, for example as input to traffic management. > > ,---------. ,---------. > |Transport| |Transport| > | Sender | |Receiver | > | |<=3D=3DFeedback=3DPath=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<| | > | ,---|<--Transport Layer returned Congestion Signal-<|<--. | > | | | | | | > | | | | | | > | | | ,-----------. | | | > | | | |(Congested)| | | | > | | |>=3DData=3DPath=3D>| Network |>=3D=3D=3D=3D=3DData=3DPath= =3D=3D=3D=3D=3D>| | | > | | | | Device |>-Congestion-Signal->|---' | > | | | `-----------' | | > | `-->|>---------(new) IP layer ConEx Signal--------->| | > | | (Carried in Data Packet Headers) | | > `---------' `---------' > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > This document serves as the entry point to the set of ConEx > documentation, giving the 'why' rather than the 'how'. A companion > document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. > > The main aim of ConEx is to support evolution of alternatives to the > proliferation of traffic management solutions that are over- > constraining, non-transparent and often not application-neutral. > Traffic management ought to be able to leave end systems free to > choose how to behave without undue interference, while simultaneously > satisfying the main concern of network operators; to control traffic > from some users that excessively limits the freedoms of others. > > Freedoms only actually collide when shared capacity becomes > congested--when a link is full so that a greater share for one user > would necessarily leave less for someone else. Current traffic > management solutions typically limit volume or bit-rate in order to > reduce the likelihood of congestion--limiting one thing in the hope > it might limit another. However, there is no real need to count > volume that is sent when there is no congestion, and there is no real > need to limit bit-rate when there is no congestion. > > ConEx markings on packets add the missing information network > operators need to get a handle on congestion itself. Then they can > directly limit and control traffic based on how much it contributes > to congestion and leave traffic unconstrained if it doesn't cause > congestion. The idea is for the operator to be able to count and > control the bulk volume or bit-rate of packets marked for congestion > and disregard packets not contributing to congestion. (There are some rewrites proposed to the above, but a paragraph summarizing some important benefits could fit here.) An example benefit for an operator is discarding packets creating excessive congestion at the ingress point where they are received from a user, reducing the required network capacity between such ingress points and the point where persistent congestion of shared capacity is occurring. This also provides a benefit to end users when operator pricing reflects this improved efficiency. Furthermore, end users with longer RTTs whose throughput was reduced as compared with users with shorter RTT will see improved throughput when persistent congestion of shared capacity occurs. > > With ConEx there is no need for the network provider to identify > specific applications or behaviours at the flow level, because the > relevant bulk congestion information is revealed at the network > layer. Also, because ConEx information is added explicitly at the IP > layer, it is visible to provider and consumer alike. Therefore > traffic contracts or acceptable use policies can be based on a metric > that is transparent to both parties and is sufficient to manage > traffic without extra non-transparent wriggle-room and caveats. > > In summary, ConEx is designed to make it simple to do traffic > management that is transparent, neutral and not over-constrained. > Although there is no implication that network operators ought to > provide such an unconstrained, transparent, neutral service, it > certainly should not be impossible and ideally it should be the > simplest service to provide. > > The IP layer is intended to engender new applications and behaviours > and to work over all existing and new lower layer technologies. > ConEx is a generative technology in this vein, with a range of > potential uses. This document focuses initially on traffic > management before widening out to introduce some additional important > uses for ConEx as well as brifly mentioning a few others. >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > >Bob Briscoe & Rich Woundy > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Wed Jun 15 06:40:43 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DFB11E8141 for ; Wed, 15 Jun 2011 06:40:43 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l-6L2UrRER9 for ; Wed, 15 Jun 2011 06:40:43 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id AF33911E8126 for ; Wed, 15 Jun 2011 06:40:42 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LsMjU-1PUx9Z3KZs-011x5o; Wed, 15 Jun 2011 15:40:38 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'Steve Bauer'" References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> In-Reply-To: <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> Date: Wed, 15 Jun 2011 14:40:34 +0100 Message-ID: <001c01cc2b61$ce2d5040$6a87f0c0$@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: AcwqxK/maLxUUyiBSsCJdScqF1IN1wAnBKXg Content-Language: en-gb X-Provags-ID: V02:K0:RkVzWAyMqii/VHSTuxHIMtSytYy+oZdmapbcG789Q08 qEgsM76LO2T9ErXweAS/R8LKfU0IHxkRLrdc3XrrVMPtLJ5GyU d+AcxGdKuHBmMHg8oRLngzsSx99X5TkPu9iPz57ROqsYyC9eGo RKpGVKZ+o43ehOhFLOw3miArG2e4LTOyyss/WT7ayVqVbC7UMu 4/Dc/7ZriHUreXr9CJRf8qdK+InhvfqLugU/eM/G8k= Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:40:43 -0000 NB, I am deliberately replying at this point in the thread, not to the additional thread between Bob and Michael... I personally agree with Steve that the word "freedom" is too emotive for this document. It works well in presentations and can be used in purely technical documents, but in a standard it runs the risk of being misconstrued. > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: 14 June 2011 19:56 > To: Steve Bauer > Cc: ConEx IETF list > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > Steve, > > I see the problem - we tried to link back to the first mention of the > word 'free', but the text could be misconstrued to mean freedom of > information, freedom of speech, freedom of association etc, not just > freedom at the traffic behaviour level. > > How about: > " Traffic management ought to be able to leave end systems free to > choose how to behave without undue interference, while > simultaneously > satisfying the main concern of network operators; to control > traffic > from some users that excessively limits the freedom of others to > send > how they want. I think this revised wording is OK as it is crystal clear what is meant by freedom at this point... > > These freedoms only actually collide when shared capacity becomes > congested... > " This is where it gets a bit tricky "freedoms colliding" sounds awfully like a political statement, not something technical standards related. There is also the problem that when one skim reads a document something like this leaps out at you because it is at the start of a para... I would tweak this sentence to read something like: "The problem comes when shared capacity becomes congested..." That still carries the same meaning but without any potential for misunderstandings. It also reads well with the remainder of that paragraph. Toby > > > Bob > > At 19:33 14/06/2011, Steve Bauer wrote: > > > Traffic management ought to be able to leave end systems free to > > > choose how to behave without undue interference, while > simultaneously > > > satisfying the main concern of network operators; to control > traffic > > > from some users that excessively limits the freedoms of others. > > > > > > Freedoms only actually collide when shared capacity becomes > > > congested--when a link is full so that a greater share for one > user > > > would necessarily leave less for someone else. > > > >One part that caused me to wince was the discussion of "freedoms". I > >don't want to equate congesting a link with stomping on other's > >liberty. You must mean this in a technical sense, so I would use > >language that is less loaded. > > > >Or maybe you deliberately choose "freedom" here? I do understand that > >these paragraphs are getting to the core of the motivation... > > > >I would have perhaps said "the main concern of network operators" was > >"to control traffic from some users that disproportionately cause > >congestion." And then maybe just strike the first sentence of the > >following paragraph which also discusses "freedoms". > > > >-Steve > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Wed Jun 15 06:46:28 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2064921F84D6 for ; Wed, 15 Jun 2011 06:46:28 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtDWPpzWDY3M for ; Wed, 15 Jun 2011 06:46:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id E82D621F84DB for ; Wed, 15 Jun 2011 06:46:26 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LrXBZ-1PWK6f1FRl-013MpL; Wed, 15 Jun 2011 15:46:24 +0200 From: "Toby Moncaster" To: "'Mcdysan, David E'" , "'ConEx IETF list'" References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> In-Reply-To: Date: Wed, 15 Jun 2011 14:46:21 +0100 Message-ID: <001d01cc2b62$9caeea00$d60cbe00$@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: AcwrXhFQTOzUYBVeStmNXRr0XCeGsAAA73qA Content-Language: en-gb X-Provags-ID: V02:K0:RyihJ3xzMbQI4sde+cfEo3PXZDyTN2WNrvBPG1CSTtm pQDtYmuCvLXPqD5Dt0ACb1Vm2FKelgGJF3y5s5E/Yc3sZrHf26 lNoh4UrA9W4z66hQ3rWYZjLHBSdnsEWvuMRg9UEfE+hCZh3eE4 +wfREONW5LnCmkkQv8bS5JNVuPIk3kPp6ODNPX0OhkGuWYZ9H6 a8oygBKsRSGosPqiYLDjztgE96jqIdxdGhGkOGzhOI= Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:46:28 -0000 Your new text is certainly a real improvement. In general I agree with most of the tweaks that have been suggested. I am not sure about Dave's suggestion of adding another paragraph about benefits--not because I think it wouldn't fit, more that I think this is just about the right length for an introduction as it stands. I do have one slight worry. I know you want to make it clear how powerful ConEx can be, but the penultimate two paragraphs have hints of tub-thumping. Having said that, I may just be being over-sensitive and over-British in my desire for restrained language! Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mcdysan, David E > Sent: 15 June 2011 14:14 > To: ConEx IETF list > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > Bob, Rich, > > This is an improved introduction. The ASCII art illustrating the > nesting > of control systems derived from the Mathis/Briscoe presentations on the > mechanism draft is most helpful in communicating the overall context > and > structure of the mechanism, and I assume that a version of this figure > will also be placed in the mechanism draft. > > IMO, the introduction needs to explain at a high-level at least one > major > benefit that will be seen by operators and end users. I would like to > be > able to give the use case document to someone who is not familiar with > conex at all and they should be able to get this message from reading > the > introduction alone. (They may not know from the introduction how these > benefits are achieved, but the summary of benefit(s) in the > introduction > should be compelling enough to motivate the reader to continue reading > more of the document.) Scanning over other responses in the thread, I > believe that Michael Menth has made a similar comment. I include some > text > for discussion in line below summarizing these benefits for discussion > by > the working group. > > Also, I think at some point in the document, the timescales over which > this third pass of the control loop operates and the high-level net > effect > of congestion encoding needs to be described. I suggest at least > inserting > the word "persistent" > > Finally, the introduction mentions shared congestion, but at some point > the document needs to address the case when a single user is causing > congestion of a non-shared queue (e.g., a DSL/cable modem). > > > Thanks, > > Dave > > > On Tuesday6/14/11 12:20 PM, "Bob Briscoe" wrote: > > >ConEx folks, > > > >After the last IETF in Prague, we agreed to work on a revised > >draft-ietf-conex-concepts-uses. We're planning on using a lot of the > >text as is, but we suggested that the Introduction needed a complete > >re-write. Below is our joint proposal. > > > >Please bash. > > > >Rationale for this Introduction: > >=============================== > >* The main change is a shift to the main target use-case in the body > >of the document: traffic management, leaving defining congestion etc > >to the definitions and concepts section (section 2). > >* Introduce enough of the solution to allow the reader to grasp the > main > >logic. > >* Introduce one primary use and mention there are others - to keep > >focused but hint at breadth. > >* Start to weave in some benefits bullet points (transparency, > >neutrality). > >* Hint at controversies like the over-provisioning issue in the first > >para, but leave addressing this to later, when we can go into the > >subject properly. > > > > > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >1. Introduction > > > > The power of Internet technology comes from multiplexing shared > > capacity with packets rather than circuits. Network operators > > usually provide sufficient capacity, but whenever too much packet > > load meets too little shared capacity, congestion results. > > Congestion appears as either increased delay, missing packets or > > packets explicitly marked with ECN [RFC3168]. The classic > Internet > > architecture is arranged so that receivers detect such signs of > > congestion and feed them back end-to-end. Then, ideally, most > > senders reduce their rate in response. > > > > The purpose of this document is to motivate a new congestion > exposure > > (ConEx) field at the IP layer. The idea is to add a third pass to > > the feedback loop so that the sender can relay congestion > information > > back into the internetwork layer, exposing the level of congestion > > the sender expects packets to experience along their whole path > > (Figure 1). Then certain network nodes can use this new > information > > at the IP layer, for example as input to traffic management. > > > > ,---------. ,------- > --. > > |Transport| > |Transport| > > | Sender | > |Receiver | > > | |<==Feedback=Path==============================<| > | > > | ,---|<--Transport Layer returned Congestion Signal-<|<--. > | > > | | | | | > | > > | | | | | > | > > | | | ,-----------. | | > | > > | | | |(Congested)| | | > | > > | | |>=Data=Path=>| Network |>=====Data=Path=====>| | > | > > | | | | Device |>-Congestion-Signal->|---' > | > > | | | `-----------' | > | > > | `-->|>---------(new) IP layer ConEx Signal--------->| > | > > | | (Carried in Data Packet Headers) | > | > > `---------' `------- > --' > > > > Figure 1: Where the ConEx Protocol Fits in the Internet > Architecture > > > > This document serves as the entry point to the set of ConEx > > documentation, giving the 'why' rather than the 'how'. A > companion > > document outlines the ConEx protocol mechanism [ConEx-Abstract- > Mech]. > > > > The main aim of ConEx is to support evolution of alternatives to > the > > proliferation of traffic management solutions that are over- > > constraining, non-transparent and often not application-neutral. > > Traffic management ought to be able to leave end systems free to > > choose how to behave without undue interference, while > simultaneously > > satisfying the main concern of network operators; to control > traffic > > from some users that excessively limits the freedoms of others. > > > > Freedoms only actually collide when shared capacity becomes > > congested--when a link is full so that a greater share for one > user > > would necessarily leave less for someone else. Current traffic > > management solutions typically limit volume or bit-rate in order > to > > reduce the likelihood of congestion--limiting one thing in the > hope > > it might limit another. However, there is no real need to count > > volume that is sent when there is no congestion, and there is no > real > > need to limit bit-rate when there is no congestion. > > > > ConEx markings on packets add the missing information network > > operators need to get a handle on congestion itself. Then they > can > > directly limit and control traffic based on how much it > contributes > > to congestion and leave traffic unconstrained if it doesn't cause > > congestion. The idea is for the operator to be able to count and > > control the bulk volume or bit-rate of packets marked for > congestion > > and disregard packets not contributing to congestion. > > (There are some rewrites proposed to the above, but a paragraph > summarizing some important benefits could fit here.) > > An example benefit for an operator is discarding packets creating > excessive congestion at the ingress point where they are received from > a > user, reducing the required network capacity between such ingress > points > and the point where persistent congestion of shared capacity is > occurring. > This also provides a benefit to end users when operator pricing > reflects > this improved efficiency. Furthermore, end users with longer RTTs whose > throughput was reduced as compared with users with shorter RTT will see > improved throughput when persistent congestion of shared capacity > occurs. > > > > > With ConEx there is no need for the network provider to identify > > specific applications or behaviours at the flow level, because the > > relevant bulk congestion information is revealed at the network > > layer. Also, because ConEx information is added explicitly at the > IP > > layer, it is visible to provider and consumer alike. Therefore > > traffic contracts or acceptable use policies can be based on a > metric > > that is transparent to both parties and is sufficient to manage > > traffic without extra non-transparent wriggle-room and caveats. > > > > In summary, ConEx is designed to make it simple to do traffic > > management that is transparent, neutral and not over-constrained. > > Although there is no implication that network operators ought to > > provide such an unconstrained, transparent, neutral service, it > > certainly should not be impossible and ideally it should be the > > simplest service to provide. > > > > The IP layer is intended to engender new applications and > behaviours > > and to work over all existing and new lower layer technologies. > > ConEx is a generative technology in this vein, with a range of > > potential uses. This document focuses initially on traffic > > management before widening out to introduce some additional > important > > uses for ConEx as well as brifly mentioning a few others. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > > >Bob Briscoe & Rich Woundy > > > > > > > >_______________________________________________ > >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 Wed Jun 15 14:39:43 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3877411E819E for ; Wed, 15 Jun 2011 14:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25fASxG4Czgm for ; Wed, 15 Jun 2011 14:39:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2716811E81A6 for ; Wed, 15 Jun 2011 14:39:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F059D33C21; Wed, 15 Jun 2011 17:39:41 -0400 (EDT) Date: Wed, 15 Jun 2011 17:39:41 -0400 From: John Leslie To: Michael Menth Message-ID: <20110615213941.GM96377@verdi> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DF84A1E.5050907@informatik.uni-tuebingen.de> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:39:43 -0000 Michael Menth wrote: > >>>>>I like this text about conex. However, I am not sure if one can >>>>>fully follow if one doesn't have the "conex background". Yesterday I started a word-smithing pass, and asked Michael for clarification about some text he proposed. Today the day-job caught up with me. :^( Nonetheless, I think it worth posting my wordsmithing. It rewords most of Bob's text "to ease the readers' task" (including simpler sentence structure, avoiding some emotion-laden terms, and moving some follow-up details closer to the first mention); and it specifically includes some of Michael's text (wordsmithed as well). If I may suggest: posting "I prefer 's text" really isn't helpful without adding a "because" clause. I reworked the Figure to have time consistently move downward. No doubt it could me shortened more -- this is still early in the wordsmithing passes. ------------------------------- cut here ------------------------------- The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators aim to provide sufficicent capacity, but when too much packet load meets too little shared capacity, congestion results. Congestion may appear as increased delay, ECN [RFC3168] marking, or dropped packets. Internet Congestion Control depends upon a feedback loop where the receiving endpoint detects such signs, feeds this detection back to the sending endpoint, and the sender reduces the sending rate. The purpose of this document is to motivate a new congestion exposure (ConEx) field at the IP layer. The idea is to extend the feedback to a complete loop, such that the sender marks as 'Congestion Expected' the level of congestion reported to it in the next packet(s) it sends. With this information, IP-layer network nodes can use this as input to traffic management. +---------+ +-----------+ +---------+ |Transport| | Congested | |Transport| | Sender | | Network | | Receiver| | |=Data=Path==>| Device |======Data=Path=====>| | | | | |-Congestion-Signal-->|-->+ | | | . . | | | | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ | | | | . . | | | | | | | | | | | |=Data=Path==>| |======Data=Path=====>| | | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ | | | . . | | | | | . . |(ignored)| | | | | | | +---------+ +-----------+ +---------+ Figure 1: Where the ConEx Protocol Fits in the Internet Architecture This document serves as the entry point to the set of ConEx documentation, giving the 'why' rather than the 'how'. A companion document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. Current traffic management solutions are not effective at managing congestion, since they limit a user's traffic based on the wrong quantities. Volume caps and/or rate limitations may not be strict enough in case of congestion, while in the absence of congestion they constrain the end systems to a mediocre capability. If the network operator tries to improve this mediocre capability, the traffic management is no longer application-neutral and frequently obscures the very problem network operators sought to fix. Traffic management solutions could work so much better with feedback about congestion at the IP layer: access rates could be constrained when necessary and high bitrates could be allowed at other times. Congestion exposure (ConEx) aims to expose exactly that information to all IP nodes on a flow's path. By having the sender ConEx-mark packets, the network operator sees the congestion along the path of that flow one round-trip-time ago. Thus the network operator can leave the task of balancing bandwidth demands to well-behaved end-systems, while still having the tools to control traffic from end-systems which don't respond appropriately to congestion signals. Network operators won't need to identify specific applications, because the same information which applications should use to manage congestion will be visible to network operators: thus it will be clear whether applications (considered as a group) are responding appropriately to congestion. Because ConEx information is added explicitly at the IP layer, it is visible to provider and consumer alike. Therefore traffic contracts or acceptable use policies can be based on a metric that is transparent to both parties and is sufficient to manage traffic without extra non-transparent wriggle-room and caveats. The IP layer is intended to enable new applications and behaviours to work over all existing and new lower-layer technologies. ConEx is a generative technology in this vein, with a range of potential uses. In summary, ConEx is designed to make it simple to have traffic management which is transparent, neutral, and not over-constrained. Although it is not our place to require traffic management to meet those characteristics, this should be the simplest service to provide (and should reduce support costs). ------------------------------- cut here ------------------------------- From menth@informatik.uni-tuebingen.de Wed Jun 15 15:23:08 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88F11E8135 for ; Wed, 15 Jun 2011 15:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyMjvIS8JTEI for ; Wed, 15 Jun 2011 15:23:07 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 842BA11E8127 for ; Wed, 15 Jun 2011 15:23:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1155C52C5; Thu, 16 Jun 2011 00:23:04 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enEj9FG7mzU7; Thu, 16 Jun 2011 00:23:00 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3C7235282; Thu, 16 Jun 2011 00:23:00 +0200 (MEST) Received: from [134.2.165.14] (vpn0264.extern.uni-tuebingen.de [134.2.165.14]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 15CF51182ECE; Thu, 16 Jun 2011 00:22:58 +0200 (CEST) Message-ID: <4DF930D2.3050108@informatik.uni-tuebingen.de> Date: Thu, 16 Jun 2011 00:23:14 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Leslie References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> In-Reply-To: <20110615213941.GM96377@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:23:08 -0000 Hi Bob, hi John, I believe the draft contains all relevant ideas. Maybe the order of the ideas could be changed a bit to shorten the text. Then there would be more room to explain the figure in more detail. What about the following order? multiplexing = power of the internet what's congestion what's the problem with current traffic management to avoid congestion what's needed to solve the problem what's the idea of ConEx Explanation of the figure ConEx is generative technology new traffic management technologies based on conex may achieve * transparency * app neutrality * not overconstrained ... purpose of this document and maybe structure Best wishes, Michael Am 15.06.2011 23:39, schrieb John Leslie: > Michael Menth wrote: >>>>>> I like this text about conex. However, I am not sure if one can >>>>>> fully follow if one doesn't have the "conex background". > Yesterday I started a word-smithing pass, and asked Michael for > clarification about some text he proposed. > > Today the day-job caught up with me. :^( > > Nonetheless, I think it worth posting my wordsmithing. It rewords > most of Bob's text "to ease the readers' task" (including simpler > sentence structure, avoiding some emotion-laden terms, and moving some > follow-up details closer to the first mention); and it specifically > includes some of Michael's text (wordsmithed as well). > > If I may suggest: posting "I prefer's text" really isn't > helpful without adding a "because" clause. > > I reworked the Figure to have time consistently move downward. > > No doubt it could me shortened more -- this is still early in the > wordsmithing passes. > > ------------------------------- cut here ------------------------------- > The power of Internet technology comes from multiplexing shared > capacity with packets rather than circuits. Network operators aim > to provide sufficicent capacity, but when too much packet load > meets too little shared capacity, congestion results. > > Congestion may appear as increased delay, ECN [RFC3168] marking, > or dropped packets. Internet Congestion Control depends upon a > feedback loop where the receiving endpoint detects such signs, > feeds this detection back to the sending endpoint, and the sender > reduces the sending rate. > > The purpose of this document is to motivate a new congestion > exposure (ConEx) field at the IP layer. The idea is to extend > the feedback to a complete loop, such that the sender marks as > 'Congestion Expected' the level of congestion reported to it in > the next packet(s) it sends. > > With this information, IP-layer network nodes can use this as input > to traffic management. > > +---------+ +-----------+ +---------+ > |Transport| | Congested | |Transport| > | Sender | | Network | | Receiver| > | |=Data=Path==>| Device |======Data=Path=====>| | > | | | |-Congestion-Signal-->|-->+ | > | | . . | | | > | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ | > | | | . . | | > | | | | | | | > | | |=Data=Path==>| |======Data=Path=====>| | > | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ | > | | . . | | | > | | . . |(ignored)| > | | | | | | > +---------+ +-----------+ +---------+ > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > This document serves as the entry point to the set of ConEx > documentation, giving the 'why' rather than the 'how'. A companion > document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. > > Current traffic management solutions are not effective at managing > congestion, since they limit a user's traffic based on the wrong > quantities. Volume caps and/or rate limitations may not be strict > enough in case of congestion, while in the absence of congestion they > constrain the end systems to a mediocre capability. If the network > operator tries to improve this mediocre capability, the traffic > management is no longer application-neutral and frequently obscures > the very problem network operators sought to fix. > > Traffic management solutions could work so much better with feedback > about congestion at the IP layer: access rates could be constrained > when necessary and high bitrates could be allowed at other times. > Congestion exposure (ConEx) aims to expose exactly that information > to all IP nodes on a flow's path. > > By having the sender ConEx-mark packets, the network operator sees > the congestion along the path of that flow one round-trip-time ago. > Thus the network operator can leave the task of balancing bandwidth > demands to well-behaved end-systems, while still having the tools to > control traffic from end-systems which don't respond appropriately > to congestion signals. > > Network operators won't need to identify specific applications, > because the same information which applications should use to manage > congestion will be visible to network operators: thus it will be > clear whether applications (considered as a group) are responding > appropriately to congestion. > > Because ConEx information is added explicitly at the IP layer, it is > visible to provider and consumer alike. Therefore traffic contracts > or acceptable use policies can be based on a metric that is > transparent to both parties and is sufficient to manage traffic > without extra non-transparent wriggle-room and caveats. > > The IP layer is intended to enable new applications and behaviours > to work over all existing and new lower-layer technologies. ConEx > is a generative technology in this vein, with a range of potential > uses. > > In summary, ConEx is designed to make it simple to have traffic > management which is transparent, neutral, and not over-constrained. > Although it is not our place to require traffic management to meet > those characteristics, this should be the simplest service to provide > (and should reduce support costs). > ------------------------------- cut here ------------------------------- -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From bob.briscoe@bt.com Thu Jun 16 02:42:00 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2985411E81AD for ; Thu, 16 Jun 2011 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+XaUJpZmDbF for ; Thu, 16 Jun 2011 02:41:59 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 4A78E228004 for ; Thu, 16 Jun 2011 02:41:59 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:41:57 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:41:57 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1308217316395; Thu, 16 Jun 2011 10:41:56 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.57]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5G9ftcw005988; Thu, 16 Jun 2011 10:41:55 +0100 Message-Id: <201106160941.p5G9ftcw005988@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Jun 2011 10:21:00 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF84A12.7040405@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> <4DF7BF43.1050104@informatik.uni-tuebingen.de> <201106142149.p5ELnp8M028850@bagheera.jungle.bt.co.uk> <4DF84A12.7040405@informatik.uni-tuebingen.de> 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: 16 Jun 2011 09:41:57.0220 (UTC) FILETIME=[A2103240:01CC2C09] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:42:00 -0000 Michael, At 06:58 15/06/2011, Michael Menth wrote: >> would necessarily leave less for someone else. Current traffic >> management solutions typically limit volume or bit-rate in order to >> reduce the likelihood of congestion--limiting one thing in the hope >> it might limit another. >in order to ... -> > >in the hope it reduces the likelihood of congestion. Done. >> However, there is no real need to count >> volume that is sent when there is no congestion, and there is no real >> need to limit bit-rate when there is no congestion. >>" > >Newbies need to know that "freedom" is basically the traffic profile >allowed by an ISP. Or even something more complicated. This text >possibly defines that implicitly by using the word freedom in this >context, but it does not define it clearly enough. I am now writing a new couple of paras based on your reordering - I'll take into account that the word freedom wasn't clear. However, altho calling it a traffic profile might be strictly correct, I think it would make people think of very specific technologies like Diffserv policers, drawing people's minds away from the many different constraints that are put on Internet traffic (limiting certain applications differently, fair queuing, volume capping etc). But we don't want to say all that yet. Sections 3 & 5 already go into all the traffic management detail. In the introduction, we only need to give the overall logic so people will understand why exposing congestion might be an answer. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Jun 16 02:49:23 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE17C11E81EE for ; Thu, 16 Jun 2011 02:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPg7QQmqoaVv for ; Thu, 16 Jun 2011 02:49:23 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id C82EC11E80F4 for ; Thu, 16 Jun 2011 02:49:22 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:49:22 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:49:21 +0100 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 1308217766726; Thu, 16 Jun 2011 10:49:26 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.57]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5G9nI8d006037; Thu, 16 Jun 2011 10:49:19 +0100 Message-Id: <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Jun 2011 10:49:17 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <001c01cc2b61$ce2d5040$6a87f0c0$@com> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> <001c01cc2b61$ce2d5040$6a87f0c0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Jun 2011 09:49:21.0370 (UTC) FILETIME=[AACC1BA0:01CC2C0A] Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:49:23 -0000 At 14:40 15/06/2011, Toby Moncaster wrote: >NB, I am deliberately replying at this point in the thread, not to the >additional thread between Bob and Michael... > >I personally agree with Steve that the word "freedom" is too emotive for >this document. It works well in presentations and can be used in purely >technical documents, but in a standard it runs the risk of being >misconstrued. > > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of Bob Briscoe > > Sent: 14 June 2011 19:56 > > To: Steve Bauer > > Cc: ConEx IETF list > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > > > Steve, > > > > I see the problem - we tried to link back to the first mention of the > > word 'free', but the text could be misconstrued to mean freedom of > > information, freedom of speech, freedom of association etc, not just > > freedom at the traffic behaviour level. > > > > How about: > > " Traffic management ought to be able to leave end systems free to > > choose how to behave without undue interference, while > > simultaneously > > satisfying the main concern of network operators; to control > > traffic > > from some users that excessively limits the freedom of others to > > send > > how they want. > >I think this revised wording is OK as it is crystal clear what is meant by >freedom at this point... > > > > > These freedoms only actually collide when shared capacity becomes > > congested... > > " > >This is where it gets a bit tricky "freedoms colliding" sounds awfully like >a political statement, not something technical standards related. There is >also the problem that when one skim reads a document something like this >leaps out at you because it is at the start of a para... > >I would tweak this sentence to read something like: > >"The problem comes when shared capacity becomes congested..." > >That still carries the same meaning but without any potential for >misunderstandings. It also reads well with the remainder of that paragraph. I don't want to imply congestion (freedoms=20 colliding) in itself is a problem - there's no=20 problem until someone always comes off badly and=20 someone else well. You will notice this is a=20 major change from the -01 intro; we've focused on=20 unsatisfactory traffic management as the problem,=20 not congestion. The body of the doc describes=20 solving traffic management as a benefit; it=20 (correctly) doesn't have removing congestion as a benefit. How about: "Everyone's freedom to send how they want is not=20 an issue unless shared capacity becomes=20 congested=97-when a link is full so that a greater=20 share for one user would necessarily leave less for someone else." (I don't want to lose the reference back to the=20 previous para just for the sake of those that skim read.) Bob >Toby > > > > > > > Bob > > > > At 19:33 14/06/2011, Steve Bauer wrote: > > > > Traffic management ought to be able to leave end systems free to > > > > choose how to behave without undue interference, while > > simultaneously > > > > satisfying the main concern of network operators; to control > > traffic > > > > from some users that excessively limits the freedoms of others. > > > > > > > > Freedoms only actually collide when shared capacity becomes > > > > congested--when a link is full so that a greater share for one > > user > > > > would necessarily leave less for someone else. > > > > > >One part that caused me to wince was the discussion of "freedoms". I > > >don't want to equate congesting a link with stomping on other's > > >liberty. You must mean this in a technical sense, so I would use > > >language that is less loaded. > > > > > >Or maybe you deliberately choose "freedom" here? I do understand that > > >these paragraphs are getting to the core of the motivation... > > > > > >I would have perhaps said "the main concern of network operators" was > > >"to control traffic from some users that disproportionately cause > > >congestion." And then maybe just strike the first sentence of the > > >following paragraph which also discusses "freedoms". > > > > > >-Steve > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From bob.briscoe@bt.com Thu Jun 16 02:49:24 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26FE11E80F4 for ; Thu, 16 Jun 2011 02:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA8FNpUijwCL for ; Thu, 16 Jun 2011 02:49:24 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id ADBAD11E8102 for ; Thu, 16 Jun 2011 02:49:23 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:49:22 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:49:21 +0100 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 1308217767648; Thu, 16 Jun 2011 10:49:27 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.57]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5G9nI8f006037; Thu, 16 Jun 2011 10:49:20 +0100 Message-Id: <201106160949.p5G9nI8f006037@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Jun 2011 10:42:00 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF84A1E.5050907@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> 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: 16 Jun 2011 09:49:21.0761 (UTC) FILETIME=[AB07C510:01CC2C0A] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:49:25 -0000 Michael, At 06:58 15/06/2011, Michael Menth wrote: >Hi Bob, > >Am 14.06.2011 23:45, schrieb Bob Briscoe: >>Michael, >> >>At 21:10 14/06/2011, Michael Menth wrote: >>>Hi Bob, >>> >>>Am 14.06.2011 20:03, schrieb Bob Briscoe: >>>>Michael, >>>> >>>>Tx for the quick turn-round. >>>> >>>>Everything you suggest makes sense. I have pasted replacement >>>>paras in the thread below to satisfy these requests. >>>> >>>>At 17:56 14/06/2011, Michael Menth wrote: >>>>>Hi Bob, >> >>[snip] >> >>> Maybe parts of the content you want to bring in the intro would >>> better fit into a conclusion? >> >>Please be more specific. Are you disagreeing with our Rationale for >>the introduction (repeated below), or are you saying we have >>written more than the rationale requires us to write? > >One can say here is the problem and that's the solution. Or one can >say: that's a new mechanism which could solve that problem. For me >the first approach is simpler, but your outline is of course also doable. > >I believe that the major challenge for a newbie in the text is the >set of used metaphoras and implicit definitions/formulations which >are partly quite dense in the sense that they are almost >conclusions. That was an obstacle for me in the very beginning of >ConEx. Being more explicit facilitates reading. Understood - we're dealing with them one by one. >>>>>>Rationale for this Introduction: >>>>>>=============================== >>>>>>* The main change is a shift to the main target use-case in the >>>>>>body of the document: traffic management, leaving defining >>>>>>congestion etc to the definitions and concepts section (section 2). >I'm not quite sure what you mean by that. Probably "change" with >respect to the existing draft, right? Yes, I meant change from the -01 draft >>>>>>* Introduce enough of the solution to allow the reader to grasp >>>>>>the main logic. >>>>>>* Introduce one primary use and mention there are others - to >>>>>>keep focused but hint at breadth. >>>>>>* Start to weave in some benefits bullet points (transparency, >>>>>>neutrality). >I am not sure what you mean by transparancy. Also neutrality could >be briefly explained in this context. The text now introduces these terms as follows: "... traffic management solutions [...] It is also hard or impossible for the operator to be open and transparent about what they will do and they are often not application-neutral." Does that help? >>>>>>* Hint at controversies like the over-provisioning issue in the >>>>>>first para, but leave addressing this to later, when we can go >>>>>>into the subject properly. >> >> >> >>>>For example in para 2 we could add: >>>>"The purpose of this doc is to ++outline the concepts necessary >>>>to understand and++ motivate a new congestion exposure (ConEx) >>>>field at the IP layer" >The purpose of this doc is to point out current problems in traffic >manament that are due to deficiencies of today's Internet >architecture. We argue that a new congestion exposure (ConEx) field >at the IP layer could provide valuable information for innovative >solutions to that problem. OK. But it's not just problem -> solution. We need to warn people that there are new concepts too. I think one of the reasons people don't get it is that they don't expect their existing set of basic concepts (like the usefulness of bit-rate and volume) to be challenged by an Internet-draft. >>>>And further down: >>>>" The ++rather radical++ idea is for the operator to be able to count and >>>> control the bulk volume or bit-rate of packets marked for congestion >> >>You haven't said whether these additions address what you were >>concerned about (if they don't I won't add them). > >My concern was more that the text is excellent for people who are >used to ConEx language but it may be difficult to read for others. > >> >>>"marked for congestion" is not clear >> >>I've changed it to >>"...control the bulk volume or bit-rate of packets with ConEx markings..." > >> >>(However, I originally avoided this because I was trying not to >>imply a particular mechanism). > >This formulation probably avoids the particular mechanism and points >out the difference to existing solutions: > >The rather radical idea is for the operator to be able to do traffic >manament based on congestion feedback from the network. While >existing mechanisms provide such information only to the source of a >flow, ConEx makes it accessible to each node on a path. We avoided saying 'to each node on the path' because this has made some people assume we require each node on the path to be changed in order to act on this new ConEx information. This is why the text talks about the IP layer rather than each node and it says "Then certain network nodes can use this new information at the IP layer, for example as input to traffic management." Cheers Bob >Michael > >> >> >>Bob >> >> >>>Michael >>> >>> >>>> and disregard packets not contributing to congestion." >>>> >>>>? >>>> >>>> >>>>Bob >>>> >>>> >>>>>Regards, >>>>> >>>>> Michael >>>>> >>>>> >>>>>> >>>>>> >>>>>>Bob Briscoe & Rich Woundy >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>conex mailing list >>>>>>conex@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/conex >>>>> >>>>>-- >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Jun 16 02:49:36 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96411E80F4 for ; Thu, 16 Jun 2011 02:49:36 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mooEVzTKd48t for ; Thu, 16 Jun 2011 02:49:35 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 9F90211E81FF for ; Thu, 16 Jun 2011 02:49:34 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:49:33 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 10:49:33 +0100 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 1308217778726; Thu, 16 Jun 2011 10:49:38 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.57]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5G9nU1w006043; Thu, 16 Jun 2011 10:49:30 +0100 Message-Id: <201106160949.p5G9nU1w006043@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Jun 2011 11:24:00 +0100 To: "Mcdysan, David E" , "Woundy, Richard" From: Bob Briscoe In-Reply-To: References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Jun 2011 09:49:33.0323 (UTC) FILETIME=[B1EBFDB0:01CC2C0A] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:49:36 -0000 David, Rich, [I've addressed Rich as co-editor directly, because there are a couple of things within that we hadn't discussed/agreed. But I think Rich is off-line at the mo, so I've kept this on-list.] Inline... At 14:13 15/06/2011, Mcdysan, David E wrote: >Bob, Rich, > >This is an improved introduction. The ASCII art illustrating the nesting >of control systems derived from the Mathis/Briscoe presentations on the >mechanism draft is most helpful in communicating the overall context and >structure of the mechanism, and I assume that a version of this figure >will also be placed in the mechanism draft. Correct (it was already there in abstract-mech-01) >IMO, the introduction needs to explain at a high-level at least one major >benefit that will be seen by operators and end users. I would like to be >able to give the use case document to someone who is not familiar with >conex at all and they should be able to get this message from reading the >introduction alone. (They may not know from the introduction how these >benefits are achieved, but the summary of benefit(s) in the introduction >should be compelling enough to motivate the reader to continue reading >more of the document.) Scanning over other responses in the thread, I >believe that Michael Menth has made a similar comment. I include some text >for discussion in line below summarizing these benefits for discussion by >the working group. Yup, I think we're all agreed on having traffic management as the one major problem and the one benefit of ConEx in the Intro - Michael's mainly helping in identifying language/concepts/metaphors that people won't understand. >Also, I think at some point in the document, the timescales over which >this third pass of the control loop operates and the high-level net effect >of congestion encoding needs to be described. I suggest at least inserting >the word "persistent" I was intending to propose that we introduce timescales in the Concepts section (S.2) when explaining congestion-rate and congestion-volume (which convolve congestion and bit-rate at queue timescales). Then we can explain that the resulting metric can be accumulated over longer timescales up to months and it still captures how 'good/bad' behaviour was at queue timescales. [However I haven't discussed this approach with my co-editor.] >Finally, the introduction mentions shared congestion, but at some point >the document needs to address the case when a single user is causing >congestion of a non-shared queue (e.g., a DSL/cable modem). In the current structure, I have this as a new "Shared Congestion" sub-section under "Potential Issues". I thought it was confusing in the -01 draft to raise this issue in the Introduction [Rich, I thought of this new home for shared congestion after our discussion on moving some parts, but omitted to seek your agreement. Agree?]. I'll post the structural changes Rich & I are proposing once the list discussion on the Introduction starts to converge. Bob >Thanks, > >Dave > > >On Tuesday6/14/11 12:20 PM, "Bob Briscoe" wrote: > > >ConEx folks, > > > >After the last IETF in Prague, we agreed to work on a revised > >draft-ietf-conex-concepts-uses. We're planning on using a lot of the > >text as is, but we suggested that the Introduction needed a complete > >re-write. Below is our joint proposal. > > > >Please bash. > > > >Rationale for this Introduction: > >=============================== > >* The main change is a shift to the main target use-case in the body > >of the document: traffic management, leaving defining congestion etc > >to the definitions and concepts section (section 2). > >* Introduce enough of the solution to allow the reader to grasp the main > >logic. > >* Introduce one primary use and mention there are others - to keep > >focused but hint at breadth. > >* Start to weave in some benefits bullet points (transparency, > >neutrality). > >* Hint at controversies like the over-provisioning issue in the first > >para, but leave addressing this to later, when we can go into the > >subject properly. > > > > > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >1. Introduction > > > > The power of Internet technology comes from multiplexing shared > > capacity with packets rather than circuits. Network operators > > usually provide sufficient capacity, but whenever too much packet > > load meets too little shared capacity, congestion results. > > Congestion appears as either increased delay, missing packets or > > packets explicitly marked with ECN [RFC3168]. The classic Internet > > architecture is arranged so that receivers detect such signs of > > congestion and feed them back end-to-end. Then, ideally, most > > senders reduce their rate in response. > > > > The purpose of this document is to motivate a new congestion exposure > > (ConEx) field at the IP layer. The idea is to add a third pass to > > the feedback loop so that the sender can relay congestion information > > back into the internetwork layer, exposing the level of congestion > > the sender expects packets to experience along their whole path > > (Figure 1). Then certain network nodes can use this new information > > at the IP layer, for example as input to traffic management. > > > > ,---------. ,---------. > > |Transport| |Transport| > > | Sender | |Receiver | > > | |<==Feedback=Path==============================<| | > > | ,---|<--Transport Layer returned Congestion Signal-<|<--. | > > | | | | | | > > | | | | | | > > | | | ,-----------. | | | > > | | | |(Congested)| | | | > > | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | > > | | | | Device |>-Congestion-Signal->|---' | > > | | | `-----------' | | > > | `-->|>---------(new) IP layer ConEx Signal--------->| | > > | | (Carried in Data Packet Headers) | | > > `---------' `---------' > > > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > > > This document serves as the entry point to the set of ConEx > > documentation, giving the 'why' rather than the 'how'. A companion > > document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. > > > > The main aim of ConEx is to support evolution of alternatives to the > > proliferation of traffic management solutions that are over- > > constraining, non-transparent and often not application-neutral. > > Traffic management ought to be able to leave end systems free to > > choose how to behave without undue interference, while simultaneously > > satisfying the main concern of network operators; to control traffic > > from some users that excessively limits the freedoms of others. > > > > Freedoms only actually collide when shared capacity becomes > > congested--when a link is full so that a greater share for one user > > would necessarily leave less for someone else. Current traffic > > management solutions typically limit volume or bit-rate in order to > > reduce the likelihood of congestion--limiting one thing in the hope > > it might limit another. However, there is no real need to count > > volume that is sent when there is no congestion, and there is no real > > need to limit bit-rate when there is no congestion. > > > > ConEx markings on packets add the missing information network > > operators need to get a handle on congestion itself. Then they can > > directly limit and control traffic based on how much it contributes > > to congestion and leave traffic unconstrained if it doesn't cause > > congestion. The idea is for the operator to be able to count and > > control the bulk volume or bit-rate of packets marked for congestion > > and disregard packets not contributing to congestion. > >(There are some rewrites proposed to the above, but a paragraph >summarizing some important benefits could fit here.) > >An example benefit for an operator is discarding packets creating >excessive congestion at the ingress point where they are received from a >user, reducing the required network capacity between such ingress points >and the point where persistent congestion of shared capacity is occurring. >This also provides a benefit to end users when operator pricing reflects >this improved efficiency. Furthermore, end users with longer RTTs whose >throughput was reduced as compared with users with shorter RTT will see >improved throughput when persistent congestion of shared capacity occurs. > > > > > With ConEx there is no need for the network provider to identify > > specific applications or behaviours at the flow level, because the > > relevant bulk congestion information is revealed at the network > > layer. Also, because ConEx information is added explicitly at the IP > > layer, it is visible to provider and consumer alike. Therefore > > traffic contracts or acceptable use policies can be based on a metric > > that is transparent to both parties and is sufficient to manage > > traffic without extra non-transparent wriggle-room and caveats. > > > > In summary, ConEx is designed to make it simple to do traffic > > management that is transparent, neutral and not over-constrained. > > Although there is no implication that network operators ought to > > provide such an unconstrained, transparent, neutral service, it > > certainly should not be impossible and ideally it should be the > > simplest service to provide. > > > > The IP layer is intended to engender new applications and behaviours > > and to work over all existing and new lower layer technologies. > > ConEx is a generative technology in this vein, with a range of > > potential uses. This document focuses initially on traffic > > management before widening out to introduce some additional important > > uses for ConEx as well as brifly mentioning a few others. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > > >Bob Briscoe & Rich Woundy > > > > > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Thu Jun 16 04:35:11 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837E021F84E7 for ; Thu, 16 Jun 2011 04:35:11 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxg80rN0NTNx for ; Thu, 16 Jun 2011 04:35:10 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36921F850B for ; Thu, 16 Jun 2011 04:35:10 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M5V4W-1PZa3H1i0m-00xbur; Thu, 16 Jun 2011 13:35:08 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <201106141855.p5EItj0x028109@bagheera.jungle.bt.co.uk> <001c01cc2b61$ce2d5040$6a87f0c0$@com> <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> In-Reply-To: <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> Date: Thu, 16 Jun 2011 12:35:05 +0100 Message-ID: <001301cc2c19$70e370a0$52aa51e0$@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: AcwsCqssW/9TAyW9SrGSDGF2x9E0HwADYABA Content-Language: en-gb X-Provags-ID: V02:K0:5NUZpRSvKMTMd/mTPFQccyt0/CQ7OizCfoYMXWutv7q +oiPxGBsp1sNaVp9l63g8SItrxJ1CZlkS1TalpsYOoqrTx4W5a Tty1/Iqdlh4WysvyshCtQgDM9aT+C9+hVSjXzVWstGDzOKh58j XeLrdirKgaSJ/lJmuJbJqpCvFIURi5w10DvppZuf1uNUK8n0+q PL7LE7NQtO3pbytvcbxmP6qIi3YJ7RvmzV9l+VRSVQ= Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 11:35:11 -0000 inline > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: 16 June 2011 10:49 > To: Toby Moncaster > Cc: 'Steve Bauer'; 'ConEx IETF list' > Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text > > At 14:40 15/06/2011, Toby Moncaster wrote: > >NB, I am deliberately replying at this point in the thread, not to the > >additional thread between Bob and Michael... > > > >I personally agree with Steve that the word "freedom" is too emotive > for > >this document. It works well in presentations and can be used in > purely > >technical documents, but in a standard it runs the risk of being > >misconstrued. > > > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > > Of Bob Briscoe > > > Sent: 14 June 2011 19:56 > > > To: Steve Bauer > > > Cc: ConEx IETF list > > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > > > > > Steve, > > > > > > I see the problem - we tried to link back to the first mention of > the > > > word 'free', but the text could be misconstrued to mean freedom of > > > information, freedom of speech, freedom of association etc, not > just > > > freedom at the traffic behaviour level. > > > > > > How about: > > > " Traffic management ought to be able to leave end systems free to > > > choose how to behave without undue interference, while > > > simultaneously > > > satisfying the main concern of network operators; to control > > > traffic > > > from some users that excessively limits the freedom of others > to > > > send > > > how they want. > > > >I think this revised wording is OK as it is crystal clear what is > meant by > >freedom at this point... > > > > > > > > These freedoms only actually collide when shared capacity > becomes > > > congested... > > > " > > > >This is where it gets a bit tricky "freedoms colliding" sounds awfully > like > >a political statement, not something technical standards related. > There is > >also the problem that when one skim reads a document something like > this > >leaps out at you because it is at the start of a para... > > > >I would tweak this sentence to read something like: > > > >"The problem comes when shared capacity becomes congested..." > > > >That still carries the same meaning but without any potential for > >misunderstandings. It also reads well with the remainder of that > paragraph. > > I don't want to imply congestion (freedoms > colliding) in itself is a problem - there's no > problem until someone always comes off badly and > someone else well. You will notice this is a > major change from the -01 intro; we've focused on > unsatisfactory traffic management as the problem, > not congestion. The body of the doc describes > solving traffic management as a benefit; it > (correctly) doesn't have removing congestion as a benefit. > > How about: > > "Everyone's freedom to send how they want is not > an issue unless shared capacity becomes > congested--when a link is full so that a greater > share for one user would necessarily leave less for someone else." That seems a bit better as it makes it clear what you mean by "freedom". Although I would be happy with that sentence, it could be even clearer if it said: "Everyone's freedom to send how they want is only an issue when shared capacity becomes congested--when a link is full so that a greater share for one user would necessarily leave less for someone else." If people are worried about complex sentence structure you could write it: "Everyone's freedom to send how they want only becomes an issue when shared capacity becomes congested. When a link is full one user getting a greater share necessarily leaves less for someone else." > > (I don't want to lose the reference back to the > previous para just for the sake of those that skim read.) Indeed - I wouldn't want you to lose it, so long as the back-reference can't be misconstrued by the skim reader... > > > Bob > > > >Toby > > > > > > > > > > > Bob > > > > > > At 19:33 14/06/2011, Steve Bauer wrote: > > > > > Traffic management ought to be able to leave end systems free > to > > > > > choose how to behave without undue interference, while > > > simultaneously > > > > > satisfying the main concern of network operators; to control > > > traffic > > > > > from some users that excessively limits the freedoms of > others. > > > > > > > > > > Freedoms only actually collide when shared capacity becomes > > > > > congested--when a link is full so that a greater share for > one > > > user > > > > > would necessarily leave less for someone else. > > > > > > > >One part that caused me to wince was the discussion of "freedoms". > I > > > >don't want to equate congesting a link with stomping on other's > > > >liberty. You must mean this in a technical sense, so I would use > > > >language that is less loaded. > > > > > > > >Or maybe you deliberately choose "freedom" here? I do understand > that > > > >these paragraphs are getting to the core of the motivation... > > > > > > > >I would have perhaps said "the main concern of network operators" > was > > > >"to control traffic from some users that disproportionately cause > > > >congestion." And then maybe just strike the first sentence of the > > > >following paragraph which also discusses "freedoms". > > > > > > > >-Steve > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT Innovate & Design > > > > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Jun 16 05:19:23 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742911E80A7 for ; Thu, 16 Jun 2011 05:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb0QCrxSVViL for ; Thu, 16 Jun 2011 05:19:22 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 716A611E808E for ; Thu, 16 Jun 2011 05:19:22 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 13:19:20 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jun 2011 13:19:20 +0100 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 1308226766195; Thu, 16 Jun 2011 13:19:26 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.57]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5GCJGQj006921; Thu, 16 Jun 2011 13:19:17 +0100 Message-Id: <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Jun 2011 13:19:17 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20110615213941.GM96377@verdi> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> 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: 16 Jun 2011 12:19:20.0298 (UTC) FILETIME=[9E938CA0:01CC2C1F] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 12:19:23 -0000 John, Thanks for this. I'll try to use as much as I can. I've only managed to respond inline to a few paras, as I have to rush to a mtg... ...rest will follow later. At 22:39 15/06/2011, John Leslie wrote: >Michael Menth wrote: > > > >>>>>I like this text about conex. However, I am not sure if one can > >>>>>fully follow if one doesn't have the "conex background". > > Yesterday I started a word-smithing pass, and asked Michael for >clarification about some text he proposed. > > Today the day-job caught up with me. :^( > > Nonetheless, I think it worth posting my wordsmithing. It rewords >most of Bob's text "to ease the readers' task" (including simpler >sentence structure, avoiding some emotion-laden terms, and moving some >follow-up details closer to the first mention); and it specifically >includes some of Michael's text (wordsmithed as well). > > If I may suggest: posting "I prefer 's text" really isn't >helpful without adding a "because" clause. > > I reworked the Figure to have time consistently move downward. > > No doubt it could me shortened more -- this is still early in the >wordsmithing passes. > >------------------------------- cut here ------------------------------- >The power of Internet technology comes from multiplexing shared >capacity with packets rather than circuits. Network operators aim >to provide sufficicent capacity, but when too much packet load >meets too little shared capacity, congestion results. > >Congestion may appear as increased delay, ECN [RFC3168] marking, >or dropped packets. Internet Congestion Control depends upon a >feedback loop where the receiving endpoint detects such signs, >feeds this detection back to the sending endpoint, and the sender >reduces the sending rate. > >The purpose of this document is to motivate a new congestion >exposure (ConEx) field at the IP layer. The idea is to extend >the feedback to a complete loop, such that the sender marks as >'Congestion Expected' the level of congestion reported to it in >the next packet(s) it sends. This removes the pointers to where we are in the diag (that Michael asked me to add, and I agreed would help lost readers). I don't think 'complete loop' is useful as people already think of it as a complete loop before ConEx. This also might make newbies think that the router that generates the congestion signal also always reads the ConEx signal. "...to add a third pass to the feedback loop" says exactly what is happening, doesn't it? >With this information, IP-layer network nodes can use this as input >to traffic management. > > +---------+ +-----------+ +---------+ > |Transport| | Congested | |Transport| > | Sender | | Network | | Receiver| > | |=Data=Path==>| Device |======Data=Path=====>| | > | | | |-Congestion-Signal-->|-->+ | > | | . . | | | > | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ | > | | | . . | | > | | | | | | | > | | |=Data=Path==>| |======Data=Path=====>| | > | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ | > | | . . | | | > | | . . |(ignored)| > | | | | | | > +---------+ +-----------+ +---------+ > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture We obviously have two different implicit y axes. You're thinking of time down the page, I'm thinking of layering. I think this shows we need to label both (layers and time). I wouldn't say 'ignored' because that could imply everything else doesn't ignore ConEx. Also, that's pre-judging how ConEx is used. I agree we could remove 'in data packet headers' because it's mechanism, but on balance I thought it might undertanding help to leave it in. >This document serves as the entry point to the set of ConEx >documentation, giving the 'why' rather than the 'how'. A companion >document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. have to go... more later... Bob >Current traffic management solutions are not effective at managing >congestion, since they limit a user's traffic based on the wrong >quantities. Volume caps and/or rate limitations may not be strict >enough in case of congestion, while in the absence of congestion they >constrain the end systems to a mediocre capability. If the network >operator tries to improve this mediocre capability, the traffic >management is no longer application-neutral and frequently obscures >the very problem network operators sought to fix. > >Traffic management solutions could work so much better with feedback >about congestion at the IP layer: access rates could be constrained >when necessary and high bitrates could be allowed at other times. >Congestion exposure (ConEx) aims to expose exactly that information >to all IP nodes on a flow's path. > >By having the sender ConEx-mark packets, the network operator sees >the congestion along the path of that flow one round-trip-time ago. >Thus the network operator can leave the task of balancing bandwidth >demands to well-behaved end-systems, while still having the tools to >control traffic from end-systems which don't respond appropriately >to congestion signals. > >Network operators won't need to identify specific applications, >because the same information which applications should use to manage >congestion will be visible to network operators: thus it will be >clear whether applications (considered as a group) are responding >appropriately to congestion. > >Because ConEx information is added explicitly at the IP layer, it is >visible to provider and consumer alike. Therefore traffic contracts >or acceptable use policies can be based on a metric that is >transparent to both parties and is sufficient to manage traffic >without extra non-transparent wriggle-room and caveats. > >The IP layer is intended to enable new applications and behaviours >to work over all existing and new lower-layer technologies. ConEx >is a generative technology in this vein, with a range of potential >uses. > >In summary, ConEx is designed to make it simple to have traffic >management which is transparent, neutral, and not over-constrained. >Although it is not our place to require traffic management to meet >those characteristics, this should be the simplest service to provide >(and should reduce support costs). >------------------------------- cut here ------------------------------- ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Thu Jun 16 06:54:31 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3491A11E8110 for ; Thu, 16 Jun 2011 06:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-UARLfwT7Jj for ; Thu, 16 Jun 2011 06:54:30 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 47A4911E810F for ; Thu, 16 Jun 2011 06:54:30 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A87B633C21; Thu, 16 Jun 2011 09:54:29 -0400 (EDT) Date: Thu, 16 Jun 2011 09:54:29 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110616135429.GN96377@verdi> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:54:31 -0000 Bob Briscoe wrote: > At 22:39 15/06/2011, John Leslie wrote: >> >> The purpose of this document is to motivate a new congestion >> exposure (ConEx) field at the IP layer. The idea is to extend >> the feedback to a complete loop, such that the sender marks as >> 'Congestion Expected' the level of congestion reported to it in >> the next packet(s) it sends. > > This removes the pointers to where we are in the diag (that Michael > asked me to add, and I agreed would help lost readers). Hmm... not sure what you mean... In any case, the reader would have forgotten this text by the time s/he gets to the diagram. > I don't think 'complete loop' is useful as people already think of it > as a complete loop before ConEx. This also might make newbies think > that the router that generates the congestion signal also always > reads the ConEx signal. I agree "loop" isn't the right word. > "...to add a third pass to the feedback loop" says exactly what is > happening, doesn't it? Perhaps in your mind... I don't think it conveys that to the reader, though. We might try something more in line with "in both directions". I think the point is that the added congestion signal needs to travel in the same direction the data experiencing congestion traveled, and needs to follow the whole path. >> +---------+ +-----------+ +---------+ >> |Transport| | Congested | |Transport| >> | Sender | | Network | | Receiver| >> | |=Data=Path==>| Device |======Data=Path=====>| | >> | | | |-Congestion-Signal-->|-->+ | >> | | . . | | | >> | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ | >> | | | . . | | >> | | | | | | | >> | | |=Data=Path==>| |======Data=Path=====>| | >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ | >> | | . . | | | >> | | . . |(ignored)| >> | | | | | | >> +---------+ +-----------+ +---------+ >> >> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > We obviously have two different implicit y axes. You're thinking of > time down the page, I'm thinking of layering. I think this shows we > need to label both (layers and time). Good catch! My Transport Layer Congestion Signal needs "=", not "-". " " | +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ | The reader expects time to be the downward Y-axis. Making it anything else will tend to confuse the reader. > I wouldn't say 'ignored' because that could imply everything else > doesn't ignore ConEx. Also, that's pre-judging how ConEx is used. I agree "ignored" isn't the right word. Perhaps "not used". > I agree we could remove 'in data packet headers' because it's > mechanism, but on balance I thought it might undertanding help > to leave it in. I don't agree. It's pure mechanism -- while "IP-layer" steers clear of mechanism. > have to go... more later... Thanks. -- John Leslie From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jun 16 09:35:36 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AF41F0C5C for ; Thu, 16 Jun 2011 09:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+xAOmV6akpl for ; Thu, 16 Jun 2011 09:35:35 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9031F0C56 for ; Thu, 16 Jun 2011 09:35:35 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C5068633B1; Thu, 16 Jun 2011 18:35:33 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B7D0159A8A; Thu, 16 Jun 2011 18:35:33 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Thu, 16 Jun 2011 18:35:32 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <001c01cc2b61$ce2d5040$6a87f0c0$@com> <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> In-Reply-To: <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201106161835.32904.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [conex] Freedom, was: draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:35:36 -0000 Hi, just a quick comment to one specific sentense: > How about: > > "Everyone's freedom to send how they want is not > an issue unless shared capacity becomes > congested -- when a link is full so that a greater > share for one user would necessarily leave less for someone else." I don't have the problem with the word 'freedom' here. But I don't think the second part is right. It might be okay to have larger share than another user at one point of time. When you are e.g. using the Internet just once a month to watch this very import video, whereas the other user is downloading stuff he never gone watch all the time everyday. Mirja From toby@moncaster.com Thu Jun 16 09:43:17 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806861F0C41 for ; Thu, 16 Jun 2011 09:43:17 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5r69ACJYlxK for ; Thu, 16 Jun 2011 09:43:16 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id F32E91F0C37 for ; Thu, 16 Jun 2011 09:43:15 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MHQzX-1QJj0G3huF-00E5gh; Thu, 16 Jun 2011 18:43:13 +0200 From: "Toby Moncaster" To: "'John Leslie'" , "'Bob Briscoe'" References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> In-Reply-To: <20110616135429.GN96377@verdi> Date: Thu, 16 Jun 2011 17:43:10 +0100 Message-ID: <002d01cc2c44$7ab9d8a0$702d89e0$@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: AcwsLPqDZiB2/NmUSla95tz1NBx/xgAFBPZg Content-Language: en-gb X-Provags-ID: V02:K0:0P+UoF8CbKC8j3qdG5/6+Oc2wi7zfqDMKfV7GnTyQe2 Ei55UMeeC08WaeN2sdmue/OyiaroiOKeXBj8zPDmYvMnZsjBzR XvfP7kun50ymlT7SIylMSvXRJ9zPHZhYI65g1jJp8bGc4ddSZY oCxWpvuGRu3qYGHEGXE3VvkzsB03v9u/C8edhW8jnDk55NVels 6DW+HzeqVsWiXMcG6Eg8V7LsxBYDkKBaPavAgHPbyg= Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:43:17 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 16 June 2011 14:54 > To: Bob Briscoe > Cc: ConEx IETF list > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > Bob Briscoe wrote: > > At 22:39 15/06/2011, John Leslie wrote: > >> > >> The purpose of this document is to motivate a new congestion > >> exposure (ConEx) field at the IP layer. The idea is to extend > >> the feedback to a complete loop, such that the sender marks as > >> 'Congestion Expected' the level of congestion reported to it in > >> the next packet(s) it sends. > > > > This removes the pointers to where we are in the diag (that Michael > > asked me to add, and I agreed would help lost readers). > > Hmm... not sure what you mean... In any case, the reader would have > forgotten this text by the time s/he gets to the diagram. Although the diagram could refer back. Personally, when I come across text like this and there is a diagram, I feel the text should point to the diagram, but should be clear enough to work for people that don't think in pictures... > > > I don't think 'complete loop' is useful as people already think of it > > as a complete loop before ConEx. This also might make newbies think > > that the router that generates the congestion signal also always > > reads the ConEx signal. > > I agree "loop" isn't the right word. Especially it isn't right as ConEx should work in transports where there is no congestion feedback. We do need to make it clear that no router needs to read the ConEx signal (though any router should be able to if it so wishes) > > > "...to add a third pass to the feedback loop" says exactly what is > > happening, doesn't it? > > Perhaps in your mind... I don't think it conveys that to the reader, > though. Surely at that point ConEx is feed-forward, not feedback? Otherwise it might sound like you expect the receiver to acknowledge how much ConEx signal it saw (which you might want as some sort of nonce for data validity, but isn't part of the core ConEx signal). I will try and think of a clearer way to express this. I know this won't just slot straight into the text, but how about: "Congestion control currently relies on the receiver informing the sender of any congestion it has seen. The sender then responds to such congestion indications in order to reduce the congestion. ConEx requires the sender to state how much congestion it expects to cause by sending a "congestion experienced" signal with any data it sends. This ConEx signal travels unchanged through the network to the receiver and can be seen at any intermediate routers or devices that choose to read it." > > We might try something more in line with "in both directions". > I think the point is that the added congestion signal needs to travel > in the same direction the data experiencing congestion traveled, and > needs to follow the whole path. And the SAME path! i.e. it shouldn't be taking the slow path in routers. > > >> +---------+ +-----------+ +------- > --+ > >> |Transport| | Congested | > |Transport| > >> | Sender | | Network | | > Receiver| > >> | |=Data=Path==>| Device |======Data=Path=====>| > | > >> | | | |-Congestion-Signal-->|-->+ > | > >> | | . . | | > | > >> | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ > | > >> | | | . . | > | > >> | | | | | | > | > >> | | |=Data=Path==>| |======Data=Path=====>| > | > >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ > | > >> | | . . | | > | > >> | | . . > |(ignored)| > >> | | | | | > | > >> +---------+ +-----------+ +------- > --+ > >> > >> Figure 1: Where the ConEx Protocol Fits in the Internet > Architecture > > > > We obviously have two different implicit y axes. You're thinking of > > time down the page, I'm thinking of layering. I think this shows we > > need to label both (layers and time). > > Good catch! My Transport Layer Congestion Signal needs "=", not "-". > " > " | +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ > | > > The reader expects time to be the downward Y-axis. Making it > anything > else will tend to confuse the reader. I actually think BOTH diagrams are useful. Bob's diagram makes it clear where ConEx fits into the existing congestion feedback architecture, while John's diagram is useful for showing the delay in the signal. I would suggest Bob's diagram is better for the introduction, but I would be keen to have John's time-based diagram included somewhere (as it will make more sense to those people who are used to such diagrams). > > > I wouldn't say 'ignored' because that could imply everything else > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is used. > > I agree "ignored" isn't the right word. Perhaps "not used". "not used" is better, since there might be a need to have a check later on (as I mentioned above), or at least paranoid end-systems might want to be able to check it! However that still has an implication that other things do "use" the signal. > > > I agree we could remove 'in data packet headers' because it's > > mechanism, but on balance I thought it might undertanding help > > to leave it in. > > I don't agree. It's pure mechanism -- while "IP-layer" steers clear > of mechanism. Agree with John - in data packet headers is mechanism. The key point here (surely) is that the signal must be visible to devices that want to see it? That sort of implies packet header, but only if you assume a packet-oriented IP layer (and I personally think ConEx can apply in other architectures in future) Toby > > > have to go... more later... > > Thanks. > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Thu Jun 16 09:46:49 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33E411E8106 for ; Thu, 16 Jun 2011 09:46:49 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggOBE7614zgk for ; Thu, 16 Jun 2011 09:46:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 88D7111E8071 for ; Thu, 16 Jun 2011 09:46:44 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MWcMY-1PzjBZ1kmg-00Xfmx; Thu, 16 Jun 2011 18:46:43 +0200 From: "Toby Moncaster" To: "'Mirja Kuehlewind'" , References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <001c01cc2b61$ce2d5040$6a87f0c0$@com> <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> <201106161835.32904.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201106161835.32904.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Thu, 16 Jun 2011 17:46:41 +0100 Message-ID: <002e01cc2c44$f85637e0$e902a7a0$@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: AcwsQ24wX03s2uYZQgqUmorY5HCw9gAARmKQ Content-Language: en-gb X-Provags-ID: V02:K0:YHFTfSlZckzkxQmT6uNsOW8NwXnF68h7NJLW9NC+m2q Gn9El+pqkTHVWLJ6pPMkGk2LEJpLbzIxf9mP49/WBozZVOinvm AR+p6r/BOSU8pubijREE0h35lPtjrhdlNi0fPOUkMuGsikaAA1 TlQDtUZ3OtFeucMuII8hABzQy65RRgP8ljh5AgzEnGsJfPf+yN u19k1Q+lBNybf9AZOtHwyKn743XIeqtpQZuejqy+Tg= Subject: Re: [conex] Freedom, was: draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:46:50 -0000 Bob isn't saying that no user can have a greater share than any other -- far from it. The whole point of ConEx is that "flow fairness" makes no sense. All Bob is saying is that, if the link is full then if one user increases their data rate every other user has to decrease theirs (or suffer markedly higher data losses). However the fact you find this confusing does suggest that Bob needs to think of a clearer way to express this. Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mirja Kuehlewind > Sent: 16 June 2011 17:36 > To: conex@ietf.org > Subject: [conex] Freedom, was: draft-ietf-conex-concepts-uses: New > Intro text > > Hi, > > just a quick comment to one specific sentense: > > > How about: > > > > "Everyone's freedom to send how they want is not > > an issue unless shared capacity becomes > > congested -- when a link is full so that a greater > > share for one user would necessarily leave less for someone else." > I don't have the problem with the word 'freedom' here. But I don't > think the > second part is right. It might be okay to have larger share than > another user > at one point of time. When you are e.g. using the Internet just once a > month > to watch this very import video, whereas the other user is downloading > stuff > he never gone watch all the time everyday. > > Mirja > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Thu Jun 16 10:43:02 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E461B11E8128 for ; Thu, 16 Jun 2011 10:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAvMBDnzsJeq for ; Thu, 16 Jun 2011 10:43:02 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F3AED11E80F1 for ; Thu, 16 Jun 2011 10:43:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2BA0533C20; Thu, 16 Jun 2011 13:43:01 -0400 (EDT) Date: Thu, 16 Jun 2011 13:43:01 -0400 From: John Leslie To: Toby Moncaster Message-ID: <20110616174301.GO96377@verdi> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002d01cc2c44$7ab9d8a0$702d89e0$@com> User-Agent: Mutt/1.4.1i Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:43:03 -0000 Toby is _much_ better at reading Bob's mind than I am! Toby Moncaster wrote: > > I will try and think of a clearer way to express this. I know this won't > just slot straight into the text, but how about: > > "Congestion control currently relies on the receiver informing the sender of > any congestion it has seen. The sender then responds to such congestion > indications in order to reduce the congestion. ConEx requires the sender to > state how much congestion it expects to cause by sending a "congestion > experienced" signal with any data it sends. This ConEx signal travels > unchanged through the network to the receiver and can be seen at any > intermediate routers or devices that choose to read it." Compare to (earlier in my wordsmithed text): ] ] Congestion may appear as increased delay, ECN [RFC3168] marking, ] or dropped packets. Internet Congestion Control depends upon a ] feedback loop where the receiving endpoint detects such signs, ] feeds this detection back to the sending endpoint, and the sender ] reduces the sending rate. (I'm not recommending anything in particular, but I'd hesitate to either add all Toby's words earlier or repeat nearly-identical text.) >> We might try something more in line with "in both directions". >> I think the point is that the added congestion signal needs to travel >> in the same direction the data experiencing congestion traveled, and >> needs to follow the whole path. > > And the SAME path! i.e. it shouldn't be taking the slow path in routers. Does that belong in an Introduction? ]] +---------+ +-----------+ +---------+ ]] |Transport| | Congested | |Transport| ]] | Sender | | Network | | Receiver| ]] | |=Data=Path==>| Device |======Data=Path=====>| | ]] | | | |-Congestion-Signal-->|-->+ | ]] | | . . | | | ]] | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ | ]] | | | . . | | ]] | | | | | | | ]] | | |=Data=Path==>| |======Data=Path=====>| | ]] | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ | ]] | | . . | | | ]] | | . . |(ignored)| ]] | | | | | | ]] +---------+ +-----------+ +---------+ ]] Figure 1: Where the ConEx Protocol Fits in the Internet ]]... >> The reader expects time to be the downward Y-axis. Making it >> anything else will tend to confuse the reader. > > I actually think BOTH diagrams are useful. Bob's diagram makes it clear > where ConEx fits into the existing congestion feedback architecture, > while John's diagram is useful for showing the delay in the signal. I tend to disagree that "Bob's diagram makes it clear where ConEx fits into the existing congestion feedback architecture": ] ] ,---------. ,---------. ] |Transport| |Transport| ] | Sender | |Receiver | ] | |<==Feedback=Path==============================<| | ] | ,---|<--Transport Layer returned Congestion Signal-<|<--. | ] | | | | | | ] | | | | | | ] | | | ,-----------. | | | ] | | | |(Congested)| | | | ] | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | ] | | | | Device |>-Congestion-Signal->|---' | ] | | | `-----------' | | ] | `-->|>---------(new) IP layer ConEx Signal--------->| | ] | | (Carried in Data Packet Headers) | | ] `---------' `---------' ] Figure 1: Where the ConEx Protocol Fits in the Internet Architecture (Of course, Toby _is_ much better at reading Bob's mind...) It confused me. "Architecture" brings up many visions, none of which prepared me to think that the Y-axis represented "layer". > I would suggest Bob's diagram is better for the introduction, but > I would be keen to have John's time-based diagram included somewhere > (as it will make more sense to those people who are used to such > diagrams). I'm perfectly happy to _have_ a diagram showing "where ConEx fits into Internet Architecture", but I'm doubtful this is it; and I think it would need a lot of text to explain it: thus I'd avoid putting it in the Introduction. -- John Lelie From toby@moncaster.com Thu Jun 16 13:26:42 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E146D11E814C for ; Thu, 16 Jun 2011 13:26:42 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crttEp45XtaB for ; Thu, 16 Jun 2011 13:26:41 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id A776411E82CB for ; Thu, 16 Jun 2011 13:26:40 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MBjiJ-1QPIFs0ml5-00ArHm; Thu, 16 Jun 2011 22:26:39 +0200 From: "Toby Moncaster" To: "'John Leslie'" References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <20110616174301.GO96377@verdi> In-Reply-To: <20110616174301.GO96377@verdi> Date: Thu, 16 Jun 2011 21:26:36 +0100 Message-ID: <003801cc2c63$b16bfad0$1443f070$@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: AcwsTNbQDaHQQSdKQQWbS4j1Gs7CYgAFI0Cw Content-Language: en-gb X-Provags-ID: V02:K0:gjzL8KiDQi+2BkuTq/ihj/Wx7V6oKRhmVzZC2V+FigG 6RAnOTuywV7A9j+L0gBR/H/3Ub/5EGO9SKTGq3ENMGe90C24tf PMtYqDDdVAINcwJaEHL6fqQ0odOFAkR7RVJuKlPDB69TNRN6oz 9oUyg2Jvsts3f1WN3PgU8kX9jZ0WjV5iJqoi92xVTJGfWLarbA K5tkmNochPK0TsGJBAC0yUWxksFwHgMgYurWM0TwGk= Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:26:43 -0000 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: 16 June 2011 18:43 > To: Toby Moncaster > Cc: 'ConEx IETF list' > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > Toby is _much_ better at reading Bob's mind than I am! > > Toby Moncaster wrote: > > > > I will try and think of a clearer way to express this. I know this > won't > > just slot straight into the text, but how about: > > > > "Congestion control currently relies on the receiver informing the > sender of > > any congestion it has seen. The sender then responds to such > congestion > > indications in order to reduce the congestion. ConEx requires the > sender to > > state how much congestion it expects to cause by sending a > "congestion > > experienced" signal with any data it sends. This ConEx signal travels > > unchanged through the network to the receiver and can be seen at any > > intermediate routers or devices that choose to read it." > > Compare to (earlier in my wordsmithed text): > ] > ] Congestion may appear as increased delay, ECN [RFC3168] marking, > ] or dropped packets. Internet Congestion Control depends upon a > ] feedback loop where the receiving endpoint detects such signs, > ] feeds this detection back to the sending endpoint, and the sender > ] reduces the sending rate. > > (I'm not recommending anything in particular, but I'd hesitate to > either add all Toby's words earlier or repeat nearly-identical text.) Certainly I wasn't thinking you could just add all my text without much bashing. I knew I was repeating text from earlier, that's why I said it can't just slot straight in. I was really just having a stream of consciousness and found it easier to include the first half to give the context for what I was saying... > > >> We might try something more in line with "in both directions". > >> I think the point is that the added congestion signal needs to > travel > >> in the same direction the data experiencing congestion traveled, and > >> needs to follow the whole path. > > > > And the SAME path! i.e. it shouldn't be taking the slow path in > routers. > > Does that belong in an Introduction? Almost certainly not... I was just making a point having got into some debate about similar stuff in PCN. > > ]] +---------+ +-----------+ +--------- > + > ]] |Transport| | Congested | > |Transport| > ]] | Sender | | Network | | > Receiver| > ]] | |=Data=Path==>| Device |======Data=Path=====>| > | > ]] | | | |-Congestion-Signal-->|-->+ > | > ]] | | . . | | > | > ]] | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ > | > ]] | | | . . | > | > ]] | | | | | | > | > ]] | | |=Data=Path==>| |======Data=Path=====>| > | > ]] | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ > | > ]] | | . . | | > | > ]] | | . . > |(ignored)| > ]] | | | | | > | > ]] +---------+ +-----------+ +--------- > + > ]] Figure 1: Where the ConEx Protocol Fits in the Internet > ]]... > >> The reader expects time to be the downward Y-axis. Making it > >> anything else will tend to confuse the reader. > > > > I actually think BOTH diagrams are useful. Bob's diagram makes it > clear > > where ConEx fits into the existing congestion feedback architecture, > > while John's diagram is useful for showing the delay in the signal. > > I tend to disagree that "Bob's diagram makes it clear where ConEx > fits > into the existing congestion feedback architecture": > ] > ] ,---------. ,---------. > ] |Transport| |Transport| > ] | Sender | |Receiver | > ] | |<==Feedback=Path==============================<| | > ] | ,---|<--Transport Layer returned Congestion Signal-<|<--. | > ] | | | | | | > ] | | | | | | > ] | | | ,-----------. | | | > ] | | | |(Congested)| | | | > ] | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | > ] | | | | Device |>-Congestion-Signal->|---' | > ] | | | `-----------' | | > ] | `-->|>---------(new) IP layer ConEx Signal--------->| | > ] | | (Carried in Data Packet Headers) | | > ] `---------' `---------' > ] Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > (Of course, Toby _is_ much better at reading Bob's mind...) > > It confused me. "Architecture" brings up many visions, none of which > prepared me to think that the Y-axis represented "layer". To me, Bob's diagram makes sense as a representation of the logical topology of how ConEx fits. Effectively it is a plan view of the logical network, with no such thing as layer. It just so happens that, because of how the Internet has evolved, the transport deals with the feedback and so the top of the loop represents a higher logical layer than the bottom of the loop, but I would never have interpreted that as a layer diagram! To me it was just an attempt to recreate this picture: < http://spectrum.ieee.org/images/dec08/images/fair03.jpg > NB Architecture is (to my mind) a rather over-used term when applied to networks. I might claim to be an expert in network architecture but I am not convinced I could explain what that meant to a complete layperson! > > > I would suggest Bob's diagram is better for the introduction, but > > I would be keen to have John's time-based diagram included somewhere > > (as it will make more sense to those people who are used to such > > diagrams). > > I'm perfectly happy to _have_ a diagram showing "where ConEx fits > into Internet Architecture", but I'm doubtful this is it; and I think > it would need a lot of text to explain it: thus I'd avoid putting it > in the Introduction. I think we are now hitting a (possibly insurmountable) problem - different people view diagrams in different ways. To me (who started my life as a civil and structural engineer, drawing and interpreting site plans) Bob's diagram makes perfect sense. But having spent 8 years in the world of networking John's diagram also makes perfect sense! I think we perhaps need a 3rd party to express an opinion here Toby > > -- > John Lelie From john@jlc.net Fri Jun 17 07:14:26 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3697611E8160 for ; Fri, 17 Jun 2011 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sh3mgunvk0N for ; Fri, 17 Jun 2011 07:14:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DE5B211E8087 for ; Fri, 17 Jun 2011 07:14:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8B29B33C21; Fri, 17 Jun 2011 10:14:24 -0400 (EDT) Date: Fri, 17 Jun 2011 10:14:24 -0400 From: John Leslie To: Toby Moncaster Message-ID: <20110617141424.GQ96377@verdi> References: <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <20110616174301.GO96377@verdi> <003801cc2c63$b16bfad0$1443f070$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003801cc2c63$b16bfad0$1443f070$@com> User-Agent: Mutt/1.4.1i Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:14:26 -0000 Toby Moncaster wrote: > [John Leslie wrote:] >> >> I tend to disagree that "Bob's diagram makes it clear where ConEx >> fits into the existing congestion feedback architecture": >>] >>] ,---------. ,---------. >>] |Transport| |Transport| >>] | Sender | |Receiver | >>] | |<==Feedback=Path==============================<| | >>] | ,---|<--Transport Layer returned Congestion Signal-<|<--. | >>] | | | | | | >>] | | | | | | >>] | | | ,-----------. | | | >>] | | | |(Congested)| | | | >>] | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | >>] | | | | Device |>-Congestion-Signal->|---' | >>] | | | `-----------' | | >>] | `-->|>---------(new) IP layer ConEx Signal--------->| | >>] | | (Carried in Data Packet Headers) | | >>] `---------' `---------' >>] Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >> >> It confused me. "Architecture" brings up many visions, none of which >> prepared me to think that the Y-axis represented "layer". > > To me, Bob's diagram makes sense as a representation of the logical > topology of how ConEx fits. (I'm not sure our typical reader thinks in terms of logical topology.) > Effectively it is a plan view of the logical network, with no such > thing as layer. I'm certain it's possible to explain it (though this doesn't quite do it for me); and I have no objection to having such a diagram so long as a sufficient explanation follows it. > It just so happens that, because of how the Internet has evolved, the > transport deals with the feedback and so the top of the loop represents > a higher logical layer than the bottom of the loop, Thus, I take it, there's no intent that the Y-axis convey layer. Looking at it long enough, I can see an outward spiral of feedback, where the new ConEx signal adds another one-way-trip. I think removing both "Carried in" and "Feedback=Path" would help, as well as balancing whitespace above and below the "Data=Path". Also, it isn't good to suggest that the new Conex signal somehow avoids going through the congested network device. But even with those modifications, I think explanatory text will be needed. > ... To me it was just an attempt to recreate this picture: > > < http://spectrum.ieee.org/images/dec08/images/fair03.jpg > (Did you forget a smiley, Toby?) > NB Architecture is (to my mind) a rather over-used term when applied > to networks. I might claim to be an expert in network architecture > but I am not convinced I could explain what that meant to a complete > layperson! I do believe we must write something an architectural-layperson can understand. > I think we are now hitting a (possibly insurmountable) problem - > different people view diagrams in different ways. Agreed -- but I don't agree it's insurmountable... > To me (who started my life as a civil and structural engineer, drawing > and interpreting site plans) Bob's diagram makes perfect sense. But > having spent 8 years in the world of networking John's diagram also > makes perfect sense! I think we perhaps need a 3rd party to express > an opinion here I've waited a bit to see if any third-party volunteered... but I think once again that "I prefer 's version" isn't helpful without a "because" clause. As it stands, it's Bob's and Rich's job to try to capture the "silent majority's" consensus. ;^) -- John Leslie From bob.briscoe@bt.com Fri Jun 17 10:38:26 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6460D11E8112 for ; Fri, 17 Jun 2011 10:38:26 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyeirH7aURG1 for ; Fri, 17 Jun 2011 10:38:25 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id E283111E80E3 for ; Fri, 17 Jun 2011 10:38:24 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 18:38:23 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Jun 2011 18:38:23 +0100 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 1308332302777; Fri, 17 Jun 2011 18:38:22 +0100 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 p5HHcJAc017303; Fri, 17 Jun 2011 18:38:19 +0100 Message-Id: <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jun 2011 18:38:21 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <002d01cc2c44$7ab9d8a0$702d89e0$@com> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> 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: 17 Jun 2011 17:38:23.0453 (UTC) FILETIME=[5B32F0D0:01CC2D15] Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:38:26 -0000 TOby, Deliberately responding to the middle of the thread, inline... At 17:43 16/06/2011, Toby Moncaster wrote: > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of John Leslie > > Sent: 16 June 2011 14:54 > > To: Bob Briscoe > > Cc: ConEx IETF list > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > > > Bob Briscoe wrote: > > > At 22:39 15/06/2011, John Leslie wrote: > > >> > > >> The purpose of this document is to motivate a new congestion > > >> exposure (ConEx) field at the IP layer. The idea is to extend > > >> the feedback to a complete loop, such that the sender marks as > > >> 'Congestion Expected' the level of congestion reported to it in > > >> the next packet(s) it sends. > > > > > > This removes the pointers to where we are in the diag (that Michael > > > asked me to add, and I agreed would help lost readers). > > > > Hmm... not sure what you mean... In any case, the reader would have > > forgotten this text by the time s/he gets to the diagram. > >Although the diagram could refer back. Personally, when I come across text >like this and there is a diagram, I feel the text should point to the >diagram, but should be clear enough to work for people that don't think in >pictures... > > > > > > I don't think 'complete loop' is useful as people already think of it > > > as a complete loop before ConEx. This also might make newbies think > > > that the router that generates the congestion signal also always > > > reads the ConEx signal. > > > > I agree "loop" isn't the right word. > >Especially it isn't right as ConEx should work in transports where there is >no congestion feedback. > >We do need to make it clear that no router needs to read the ConEx signal >(though any router should be able to if it so wishes) We don't even need to say the parenthesis. > > > > > "...to add a third pass to the feedback loop" says exactly what is > > > happening, doesn't it? > > > > Perhaps in your mind... I don't think it conveys that to the reader, > > though. > >Surely at that point ConEx is feed-forward, not feedback? Otherwise it might >sound like you expect the receiver to acknowledge how much ConEx signal it >saw (which you might want as some sort of nonce for data validity, but isn't >part of the core ConEx signal). > >I will try and think of a clearer way to express this. I know this won't >just slot straight into the text, but how about: > >"Congestion control currently relies on the receiver informing the sender of >any congestion it has seen. The sender then responds to such congestion >indications in order to reduce the congestion. ConEx requires the sender to >state how much congestion it expects to cause by sending a "congestion >experienced" signal with any data it sends. This ConEx signal travels >unchanged through the network to the receiver and can be seen at any >intermediate routers or devices that choose to read it." That's pretty good. But again, I would deconfuse by simply saying: s/intermediate routers or devices/IP layer devices/ > > > > We might try something more in line with "in both directions". > > I think the point is that the added congestion signal needs to travel > > in the same direction the data experiencing congestion traveled, and > > needs to follow the whole path. > >And the SAME path! i.e. it shouldn't be taking the slow path in routers. Fast/slow path is mechanism. Same path isn't absolutely necessary, as long as it's typical. Like packets of a flow, they can change path, but you don't want them to have to be pinned ONLY to one path. So I wouldn't bring path up here (this is introduction). > > > > >> +---------+ +-----------+ +------- > > --+ > > >> |Transport| | Congested | > > |Transport| > > >> | Sender | | Network | | > > Receiver| > > >> | |=Data=Path==>| Device |======Data=Path=====>| > > | > > >> | | | |-Congestion-Signal-->|-->+ > > | > > >> | | . . | | > > | > > >> | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ > > | > > >> | | | . . | > > | > > >> | | | | | | > > | > > >> | | |=Data=Path==>| |======Data=Path=====>| > > | > > >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ > > | > > >> | | . . | | > > | > > >> | | . . > > |(ignored)| > > >> | | | | | > > | > > >> +---------+ +-----------+ +------- > > --+ > > >> > > >> Figure 1: Where the ConEx Protocol Fits in the Internet > > Architecture > > > > > > We obviously have two different implicit y axes. You're thinking of > > > time down the page, I'm thinking of layering. I think this shows we > > > need to label both (layers and time). > > > > Good catch! My Transport Layer Congestion Signal needs "=", not "-". > > " > > " | +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ > > | > > > > The reader expects time to be the downward Y-axis. Making it > > anything > > else will tend to confuse the reader. I think John means "confuse readers who think like John" My suggestion was to label the axis, so people don't have to guess. Then we don't have to continue this discussion. If we discuss what "expected" congestion is, that should be under section 2, which we plan to re-title as Concepts, rather than just Definitions. That's also where I promised David we would discuss the timescale subtelties of the congestion-volume metric. >I actually think BOTH diagrams are useful. Bob's diagram makes it clear >where ConEx fits into the existing congestion feedback architecture, while >John's diagram is useful for showing the delay in the signal. I would >suggest Bob's diagram is better for the introduction, but I would be keen to >have John's time-based diagram included somewhere (as it will make more >sense to those people who are used to such diagrams). People expect a protocol timing diag to have diagonal lines. Personally I don't think we should try to discuss protocol timing in concepts-uses. It's virtually impossible to talk about it in a mechanism-neutral way. We have this in abstract-mech (I can't remember if it's in the published version or the next rev that has my updates and is sitting waiting for Matt to add his). > > > > > I wouldn't say 'ignored' because that could imply everything else > > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is used. > > > > I agree "ignored" isn't the right word. Perhaps "not used". > >"not used" is better, since there might be a need to have a check later on >(as I mentioned above), or at least paranoid end-systems might want to be >able to check it! However that still has an implication that other things do >"use" the signal. As I said once, saying "not used", "ignored" or anything here is pre-judging how ConEx is used by the receiver. This was deliberately left blank. > > > > > I agree we could remove 'in data packet headers' because it's > > > mechanism, but on balance I thought it might undertanding help > > > to leave it in. > > > > I don't agree. It's pure mechanism -- while "IP-layer" steers clear > > of mechanism. > >Agree with John - in data packet headers is mechanism. The key point here >(surely) is that the signal must be visible to devices that want to see it? >That sort of implies packet header, but only if you assume a packet-oriented >IP layer (and I personally think ConEx can apply in other architectures in >future) Er, can we stay a little grounded here. This is the IETF, not the "Inter-Galactic Packet Network Standards Force". For the IETF, "in the IP layer" means the same as "in IP packet headers". Because there is only IP payload and IP headers in the IP layer. And we're not putting ConEx in the payload. In concepts-uses we are only not talking about mechanism in order not to pre-judge later decisions. There is no alternative on the table other than signalling ConEx in data packet headers, so we can assume it. If we abstract for abstraction's sake, no-one will understand. Bob >Toby > > > > > > > have to go... more later... > > > > Thanks. > > > > -- > > John Leslie > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Fri Jun 17 11:15:31 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4D11E811D for ; Fri, 17 Jun 2011 11:15:31 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXHzq8ZvYG9G for ; Fri, 17 Jun 2011 11:15:30 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 42A9A9E8004 for ; Fri, 17 Jun 2011 11:15:30 -0700 (PDT) Received: from TobysHP (host86-156-54-97.range86-156.btcentralplus.com [86.156.54.97]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MPeS5-1QSwbn3Qyv-004ft4; Fri, 17 Jun 2011 20:15:27 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> In-Reply-To: <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> Date: Fri, 17 Jun 2011 19:15:23 +0100 Message-ID: <000d01cc2d1a$86ed9ae0$94c8d0a0$@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: AcwtFVuGF/dPPv66Tx+yqb6VT7UjtgAA5REA Content-Language: en-gb X-Provags-ID: V02:K0:FVmt633aEwNaGIJwwvN14vtb4+rVWx1Ceagke1uIldp 7CiFqWi2P8SKlLy6/gMpMyhN/C3V40gvYgX+xNjuLtEe7yp4xi OIXb68OZrbZeI8R4/q3KbFflzTKxZaRiFjOQwNuhDrpDQZj5Oh Cvj0wi4uoNBvqKRkTw0pQG6bsHQThYCejtanl/h+nKeysSvOrk X/R79mdt2qTblImk06qUJhfQmdSHmgsNqQ/0LvRGCA= Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:15:31 -0000 > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: 17 June 2011 18:38 > To: Toby Moncaster > Cc: 'John Leslie'; 'ConEx IETF list' > Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text > > TOby, > > Deliberately responding to the middle of the thread, inline... > > At 17:43 16/06/2011, Toby Moncaster wrote: > > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > > Of John Leslie > > > Sent: 16 June 2011 14:54 > > > To: Bob Briscoe > > > Cc: ConEx IETF list > > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > > > > > Bob Briscoe wrote: > > > > At 22:39 15/06/2011, John Leslie wrote: > > > >> > > > >> The purpose of this document is to motivate a new congestion > > > >> exposure (ConEx) field at the IP layer. The idea is to extend > > > >> the feedback to a complete loop, such that the sender marks as > > > >> 'Congestion Expected' the level of congestion reported to it in > > > >> the next packet(s) it sends. > > > > > > > > This removes the pointers to where we are in the diag (that > Michael > > > > asked me to add, and I agreed would help lost readers). > > > > > > Hmm... not sure what you mean... In any case, the reader would > have > > > forgotten this text by the time s/he gets to the diagram. > > > >Although the diagram could refer back. Personally, when I come across > text > >like this and there is a diagram, I feel the text should point to the > >diagram, but should be clear enough to work for people that don't > think in > >pictures... > > > > > > > > > I don't think 'complete loop' is useful as people already think > of it > > > > as a complete loop before ConEx. This also might make newbies > think > > > > that the router that generates the congestion signal also always > > > > reads the ConEx signal. > > > > > > I agree "loop" isn't the right word. > > > >Especially it isn't right as ConEx should work in transports where > there is > >no congestion feedback. > > > >We do need to make it clear that no router needs to read the ConEx > signal > >(though any router should be able to if it so wishes) > > We don't even need to say the parenthesis. Indeed. I just wanted to make it clear to people reading this thread -- there are still people that believe ConEx requires every device to understand it > > > > > > > > > "...to add a third pass to the feedback loop" says exactly what > is > > > > happening, doesn't it? > > > > > > Perhaps in your mind... I don't think it conveys that to the > reader, > > > though. > > > >Surely at that point ConEx is feed-forward, not feedback? Otherwise it > might > >sound like you expect the receiver to acknowledge how much ConEx > signal it > >saw (which you might want as some sort of nonce for data validity, but > isn't > >part of the core ConEx signal). > > > >I will try and think of a clearer way to express this. I know this > won't > >just slot straight into the text, but how about: > > > >"Congestion control currently relies on the receiver informing the > sender of > >any congestion it has seen. The sender then responds to such > congestion > >indications in order to reduce the congestion. ConEx requires the > sender to > >state how much congestion it expects to cause by sending a "congestion > >experienced" signal with any data it sends. This ConEx signal travels > >unchanged through the network to the receiver and can be seen at any > >intermediate routers or devices that choose to read it." > > That's pretty good. But again, I would deconfuse by simply saying: > s/intermediate routers or devices/IP layer devices/ That is clearer and covers all sensible possibilities. > > > > > > > > We might try something more in line with "in both directions". > > > I think the point is that the added congestion signal needs to > travel > > > in the same direction the data experiencing congestion traveled, > and > > > needs to follow the whole path. > > > >And the SAME path! i.e. it shouldn't be taking the slow path in > routers. > > Fast/slow path is mechanism. OK, fair point. > > Same path isn't absolutely necessary, as long as it's typical. Like > packets of a flow, they can change path, but you don't want them to > have to be pinned ONLY to one path. So I wouldn't bring path up here > (this is introduction). OK you're right that we don't want too much detail in an introduction. There might be a need to discuss these sort of details in another document (perhaps as an appendix?) > > > > > > > > > >> +---------+ +-----------+ +--- > ---- > > > --+ > > > >> |Transport| | Congested | > > > |Transport| > > > >> | Sender | | Network | | > > > Receiver| > > > >> | |=Data=Path==>| Device |======Data=Path=====>| > > > | > > > >> | | | |-Congestion-Signal-->|-- > >+ > > > | > > > >> | | . . | > | > > > | > > > >> | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<-- > + > > > | > > > >> | | | . . | > > > | > > > >> | | | | | | > > > | > > > >> | | |=Data=Path==>| |======Data=Path=====>| > > > | > > > >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-- > >+ > > > | > > > >> | | . . | > | > > > | > > > >> | | . . > > > |(ignored)| > > > >> | | | | | > > > | > > > >> +---------+ +-----------+ +--- > ---- > > > --+ > > > >> > > > >> Figure 1: Where the ConEx Protocol Fits in the Internet > > > Architecture > > > > > > > > We obviously have two different implicit y axes. You're thinking > of > > > > time down the page, I'm thinking of layering. I think this shows > we > > > > need to label both (layers and time). > > > > > > Good catch! My Transport Layer Congestion Signal needs "=", not > "-". > > > " > > > " | +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ > > > | > > > > > > The reader expects time to be the downward Y-axis. Making it > > > anything > > > else will tend to confuse the reader. > > I think John means "confuse readers who think like John" > My suggestion was to label the axis, so people don't have to guess. > Then we don't have to continue this discussion. Diagrams are always hard because people see them differently. > > If we discuss what "expected" congestion is, that should be under > section 2, which we plan to re-title as Concepts, rather than just > Definitions. Yes, fair enough - expected needs actual explanation > > That's also where I promised David we would discuss the timescale > subtelties of the congestion-volume metric. > > > >I actually think BOTH diagrams are useful. Bob's diagram makes it > clear > >where ConEx fits into the existing congestion feedback architecture, > while > >John's diagram is useful for showing the delay in the signal. I would > >suggest Bob's diagram is better for the introduction, but I would be > keen to > >have John's time-based diagram included somewhere (as it will make > more > >sense to those people who are used to such diagrams). > > People expect a protocol timing diag to have diagonal lines. Agreed, that is a mechanism thing > > Personally I don't think we should try to discuss protocol timing in > concepts-uses. It's virtually impossible to talk about it in a > mechanism-neutral way. I am actually not 100% sure you can avoid all mechanism and protocol details whilst still having a concepts and use cases document that makes sense. I know we have to ensure that the majority of mechanism is in abstract-mech, but you may need a bit in order to explain the concept > > We have this in abstract-mech (I can't remember if it's in the > published version or the next rev that has my updates and is sitting > waiting for Matt to add his). > > > > > > > > > I wouldn't say 'ignored' because that could imply everything else > > > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is used. > > > > > > I agree "ignored" isn't the right word. Perhaps "not used". > > > >"not used" is better, since there might be a need to have a check > later on > >(as I mentioned above), or at least paranoid end-systems might want to > be > >able to check it! However that still has an implication that other > things do > >"use" the signal. > > As I said once, saying "not used", "ignored" or anything here is > pre-judging how ConEx is used by the receiver. This was deliberately > left blank. > OK, I have now looked back at your diagram and agree that it is much clearer without this > > > > > > > > I agree we could remove 'in data packet headers' because it's > > > > mechanism, but on balance I thought it might undertanding help > > > > to leave it in. > > > > > > I don't agree. It's pure mechanism -- while "IP-layer" steers > clear > > > of mechanism. > > > >Agree with John - in data packet headers is mechanism. The key point > here > >(surely) is that the signal must be visible to devices that want to > see it? > >That sort of implies packet header, but only if you assume a packet- > oriented > >IP layer (and I personally think ConEx can apply in other > architectures in > >future) > > Er, can we stay a little grounded here. This is the IETF, not the > "Inter-Galactic Packet Network Standards Force". I know! > > For the IETF, "in the IP layer" means the same as "in IP packet > headers". Because there is only IP payload and IP headers in the IP > layer. And we're not putting ConEx in the payload. So let's say "in the IP layer". As soon as you explicitly state in the packet header you will get shouts of "mechanism" (though this is perhaps a case in point where you will find it hard to excise all mechanism from this document) > > In concepts-uses we are only not talking about mechanism in order not > to pre-judge later decisions. There is no alternative on the table > other than signalling ConEx in data packet headers, so we can assume > it. If we abstract for abstraction's sake, no-one will understand. I don't see how not specifying where the conex info is carried is going to confuse? One key driver for keeping the mechanism out of this draft was that I got told off by the WGCs for having mechanism in an earlier version... Toby > > > Bob > > > >Toby > > > > > > > > > > > have to go... more later... > > > > > > Thanks. > > > > > > -- > > > John Leslie > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Jun 23 05:18:08 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C742A11E816A for ; Thu, 23 Jun 2011 05:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7emVHIcPrFhM for ; Thu, 23 Jun 2011 05:18:07 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 851BA11E8165 for ; Thu, 23 Jun 2011 05:18:07 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 13:18:05 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 13:18:05 +0100 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 1308831485229; Thu, 23 Jun 2011 13:18:05 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.103]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5NCI1WR023363; Thu, 23 Jun 2011 13:18:01 +0100 Message-Id: <201106231218.p5NCI1WR023363@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Jun 2011 13:17:58 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <002e01cc2c44$f85637e0$e902a7a0$@com> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <001c01cc2b61$ce2d5040$6a87f0c0$@com> <201106160949.p5G9nI8d006037@bagheera.jungle.bt.co.uk> <201106161835.32904.mirja.kuehlewind@ikr.uni-stuttgart.de> <002e01cc2c44$f85637e0$e902a7a0$@com> 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: 23 Jun 2011 12:18:05.0356 (UTC) FILETIME=[9ACC8EC0:01CC319F] Cc: conex@ietf.org Subject: Re: [conex] Freedom, was: draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 12:18:08 -0000 Toby, Mirja, Point taken - I'll clarify. I won't suggest wording until I've absorbed all the emails I need to catch up on. [Sorry for nearly a week's gap since I was last on-list. I was given a "little task".] Bob At 17:46 16/06/2011, Toby Moncaster wrote: >Bob isn't saying that no user can have a greater share than any other -- far >from it. The whole point of ConEx is that "flow fairness" makes no sense. > >All Bob is saying is that, if the link is full then if one user increases >their data rate every other user has to decrease theirs (or suffer markedly >higher data losses). > >However the fact you find this confusing does suggest that Bob needs to >think of a clearer way to express this. > >Toby > > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of Mirja Kuehlewind > > Sent: 16 June 2011 17:36 > > To: conex@ietf.org > > Subject: [conex] Freedom, was: draft-ietf-conex-concepts-uses: New > > Intro text > > > > Hi, > > > > just a quick comment to one specific sentense: > > > > > How about: > > > > > > "Everyone's freedom to send how they want is not > > > an issue unless shared capacity becomes > > > congested -- when a link is full so that a greater > > > share for one user would necessarily leave less for someone else." > > I don't have the problem with the word 'freedom' here. But I don't > > think the > > second part is right. It might be okay to have larger share than > > another user > > at one point of time. When you are e.g. using the Internet just once a > > month > > to watch this very import video, whereas the other user is downloading > > stuff > > he never gone watch all the time everyday. > > > > Mirja > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Jun 23 08:09:16 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B04411E811A for ; Thu, 23 Jun 2011 08:09:16 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxf9JvywCNGb for ; Thu, 23 Jun 2011 08:09:15 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 994B011E8096 for ; Thu, 23 Jun 2011 08:09:14 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 16:09:12 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 16:09:12 +0100 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 1308841751956; Thu, 23 Jun 2011 16:09:11 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.16.7]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5NF99pk024048; Thu, 23 Jun 2011 16:09:09 +0100 Message-Id: <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Jun 2011 16:06:34 +0100 To: Marcelo BAGNULO BRAUN , Nandita Dukkipati From: Bob Briscoe In-Reply-To: <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> 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: 23 Jun 2011 15:09:12.0521 (UTC) FILETIME=[82819B90:01CC31B7] Cc: 'ConEx IETF list' Subject: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 15:09:16 -0000 Marcelo, Nandita, Pls give guidance as wg chairs, so we don't write text you will later ask us to remove... We (the editors) are having trouble with the requirement not to describe mechanism in conex-concepts-uses. People on the list seem to agree that some very high level description of ConEx mechanism is necessary in order to make sense of following text. The question is, where to draw the line. Certainly, it is good discipline to be able to describe the problem without describing the mechanism of a solution. But concepts-uses covers more than the problem. It also has to describe central concepts. If we describe central concepts without some degree of mechanism description, it's going to be one of those weird documents that commits to nothing and becomes content-free. For example... The list seems happy that something pirtched at the level of how the ConEx charter describes the mechanism is fine (plus a picture a bit like the first one in abstract-mech). But we seem to need more to support later text. For example: 1/ Timing In the Concepts section (the new name for section 2 on Definitions) we plan to explain what we mean by 'expected congestion' by talking about the sender starting off signalling a conservative expectation of congestion when it has no info about the path, then once it gets e2e transport feedback, it can continually re-insert the feedback into the IP layer as its expectation of congestion. 2/ Headers I prefer to say ConEx info is put in packet headers at the IP layer. Some argue we should just say "at the IP layer" without mentioning headers. I think it's clearer to mention packet headers. My logic is that the rule against speaking about mechanism is primarily designed to avoid prejudging later mechanism documents. However, if abstract-mech is already settled on a decision, and if describing it in concepts-uses is essential background to explain a concept, I would rather just do that, than dance around in abstract-land. Otherwise readers might imagine we could be talking about backward ICMP messages or something, and get confused. Bob At 19:15 17/06/2011, Toby Moncaster wrote: > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: 17 June 2011 18:38 > > To: Toby Moncaster > > Cc: 'John Leslie'; 'ConEx IETF list' > > Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text > > > > TOby, > > > > Deliberately responding to the middle of the thread, inline... > > > > At 17:43 16/06/2011, Toby Moncaster wrote: > > > > > > -----Original Message----- > > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > > Behalf > > > > Of John Leslie > > > > Sent: 16 June 2011 14:54 > > > > To: Bob Briscoe > > > > Cc: ConEx IETF list > > > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text > > > > > > > > Bob Briscoe wrote: > > > > > At 22:39 15/06/2011, John Leslie wrote: > > > > >> > > > > >> The purpose of this document is to motivate a new congestion > > > > >> exposure (ConEx) field at the IP layer. The idea is to extend > > > > >> the feedback to a complete loop, such that the sender marks as > > > > >> 'Congestion Expected' the level of congestion reported to it in > > > > >> the next packet(s) it sends. > > > > > > > > > > This removes the pointers to where we are in the diag (that > > Michael > > > > > asked me to add, and I agreed would help lost readers). > > > > > > > > Hmm... not sure what you mean... In any case, the reader would > > have > > > > forgotten this text by the time s/he gets to the diagram. > > > > > >Although the diagram could refer back. Personally, when I come across > > text > > >like this and there is a diagram, I feel the text should point to the > > >diagram, but should be clear enough to work for people that don't > > think in > > >pictures... > > > > > > > > > > > > I don't think 'complete loop' is useful as people already think > > of it > > > > > as a complete loop before ConEx. This also might make newbies > > think > > > > > that the router that generates the congestion signal also always > > > > > reads the ConEx signal. > > > > > > > > I agree "loop" isn't the right word. > > > > > >Especially it isn't right as ConEx should work in transports where > > there is > > >no congestion feedback. > > > > > >We do need to make it clear that no router needs to read the ConEx > > signal > > >(though any router should be able to if it so wishes) > > > > We don't even need to say the parenthesis. > >Indeed. I just wanted to make it clear to people reading this thread -- >there are still people that believe ConEx requires every device to >understand it > > > > > > > > > > > > > > "...to add a third pass to the feedback loop" says exactly what > > is > > > > > happening, doesn't it? > > > > > > > > Perhaps in your mind... I don't think it conveys that to the > > reader, > > > > though. > > > > > >Surely at that point ConEx is feed-forward, not feedback? Otherwise it > > might > > >sound like you expect the receiver to acknowledge how much ConEx > > signal it > > >saw (which you might want as some sort of nonce for data validity, but > > isn't > > >part of the core ConEx signal). > > > > > >I will try and think of a clearer way to express this. I know this > > won't > > >just slot straight into the text, but how about: > > > > > >"Congestion control currently relies on the receiver informing the > > sender of > > >any congestion it has seen. The sender then responds to such > > congestion > > >indications in order to reduce the congestion. ConEx requires the > > sender to > > >state how much congestion it expects to cause by sending a "congestion > > >experienced" signal with any data it sends. This ConEx signal travels > > >unchanged through the network to the receiver and can be seen at any > > >intermediate routers or devices that choose to read it." > > > > That's pretty good. But again, I would deconfuse by simply saying: > > s/intermediate routers or devices/IP layer devices/ > >That is clearer and covers all sensible possibilities. > > > > > > > > > > > > > We might try something more in line with "in both directions". > > > > I think the point is that the added congestion signal needs to > > travel > > > > in the same direction the data experiencing congestion traveled, > > and > > > > needs to follow the whole path. > > > > > >And the SAME path! i.e. it shouldn't be taking the slow path in > > routers. > > > > Fast/slow path is mechanism. > >OK, fair point. > > > > > Same path isn't absolutely necessary, as long as it's typical. Like > > packets of a flow, they can change path, but you don't want them to > > have to be pinned ONLY to one path. So I wouldn't bring path up here > > (this is introduction). > >OK you're right that we don't want too much detail in an introduction. There >might be a need to discuss these sort of details in another document >(perhaps as an appendix?) > > > > > > > > > > > > > > > >> +---------+ +-----------+ +--- > > ---- > > > > --+ > > > > >> |Transport| | Congested | > > > > |Transport| > > > > >> | Sender | | Network | | > > > > Receiver| > > > > >> | |=Data=Path==>| Device |======Data=Path=====>| > > > > | > > > > >> | | | |-Congestion-Signal-->|-- > > >+ > > > > | > > > > >> | | . . | > > | > > > > | > > > > >> | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<-- > > + > > > > | > > > > >> | | | . . | > > > > | > > > > >> | | | | | | > > > > | > > > > >> | | |=Data=Path==>| |======Data=Path=====>| > > > > | > > > > >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-- > > >+ > > > > | > > > > >> | | . . | > > | > > > > | > > > > >> | | . . > > > > |(ignored)| > > > > >> | | | | | > > > > | > > > > >> +---------+ +-----------+ +--- > > ---- > > > > --+ > > > > >> > > > > >> Figure 1: Where the ConEx Protocol Fits in the Internet > > > > Architecture > > > > > > > > > > We obviously have two different implicit y axes. You're thinking > > of > > > > > time down the page, I'm thinking of layering. I think this shows > > we > > > > > need to label both (layers and time). > > > > > > > > Good catch! My Transport Layer Congestion Signal needs "=", not > > "-". > > > > " > > > > " | +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ > > > > | > > > > > > > > The reader expects time to be the downward Y-axis. Making it > > > > anything > > > > else will tend to confuse the reader. > > > > I think John means "confuse readers who think like John" > > My suggestion was to label the axis, so people don't have to guess. > > Then we don't have to continue this discussion. > >Diagrams are always hard because people see them differently. > > > > > If we discuss what "expected" congestion is, that should be under > > section 2, which we plan to re-title as Concepts, rather than just > > Definitions. > >Yes, fair enough - expected needs actual explanation > > > > > That's also where I promised David we would discuss the timescale > > subtelties of the congestion-volume metric. > > > > > > >I actually think BOTH diagrams are useful. Bob's diagram makes it > > clear > > >where ConEx fits into the existing congestion feedback architecture, > > while > > >John's diagram is useful for showing the delay in the signal. I would > > >suggest Bob's diagram is better for the introduction, but I would be > > keen to > > >have John's time-based diagram included somewhere (as it will make > > more > > >sense to those people who are used to such diagrams). > > > > People expect a protocol timing diag to have diagonal lines. > >Agreed, that is a mechanism thing > > > > > Personally I don't think we should try to discuss protocol timing in > > concepts-uses. It's virtually impossible to talk about it in a > > mechanism-neutral way. > >I am actually not 100% sure you can avoid all mechanism and protocol details >whilst still having a concepts and use cases document that makes sense. I >know we have to ensure that the majority of mechanism is in abstract-mech, >but you may need a bit in order to explain the concept > > > > > We have this in abstract-mech (I can't remember if it's in the > > published version or the next rev that has my updates and is sitting > > waiting for Matt to add his). > > > > > > > > > > > > > I wouldn't say 'ignored' because that could imply everything else > > > > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is used. > > > > > > > > I agree "ignored" isn't the right word. Perhaps "not used". > > > > > >"not used" is better, since there might be a need to have a check > > later on > > >(as I mentioned above), or at least paranoid end-systems might want to > > be > > >able to check it! However that still has an implication that other > > things do > > >"use" the signal. > > > > As I said once, saying "not used", "ignored" or anything here is > > pre-judging how ConEx is used by the receiver. This was deliberately > > left blank. > > > >OK, I have now looked back at your diagram and agree that it is much clearer >without this > > > > > > > > > > > > I agree we could remove 'in data packet headers' because it's > > > > > mechanism, but on balance I thought it might undertanding help > > > > > to leave it in. > > > > > > > > I don't agree. It's pure mechanism -- while "IP-layer" steers > > clear > > > > of mechanism. > > > > > >Agree with John - in data packet headers is mechanism. The key point > > here > > >(surely) is that the signal must be visible to devices that want to > > see it? > > >That sort of implies packet header, but only if you assume a packet- > > oriented > > >IP layer (and I personally think ConEx can apply in other > > architectures in > > >future) > > > > Er, can we stay a little grounded here. This is the IETF, not the > > "Inter-Galactic Packet Network Standards Force". > >I know! > > > > > For the IETF, "in the IP layer" means the same as "in IP packet > > headers". Because there is only IP payload and IP headers in the IP > > layer. And we're not putting ConEx in the payload. > >So let's say "in the IP layer". As soon as you explicitly state in the >packet header you will get shouts of "mechanism" (though this is perhaps a >case in point where you will find it hard to excise all mechanism from this >document) > > > > > In concepts-uses we are only not talking about mechanism in order not > > to pre-judge later decisions. There is no alternative on the table > > other than signalling ConEx in data packet headers, so we can assume > > it. If we abstract for abstraction's sake, no-one will understand. > >I don't see how not specifying where the conex info is carried is going to >confuse? > >One key driver for keeping the mechanism out of this draft was that I got >told off by the WGCs for having mechanism in an earlier version... > >Toby > > > > > > > Bob > > > > > > >Toby > > > > > > > > > > > > > > > have to go... more later... > > > > > > > > Thanks. > > > > > > > > -- > > > > John Leslie > > > > _______________________________________________ > > > > conex mailing list > > > > conex@ietf.org > > > > https://www.ietf.org/mailman/listinfo/conex > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Jun 23 13:21:21 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A813711E8180 for ; Thu, 23 Jun 2011 13:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of2jUUjQPqVD for ; Thu, 23 Jun 2011 13:21:20 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61A11E817E for ; Thu, 23 Jun 2011 13:21:18 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 21:21:17 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 21:21:16 +0100 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 130886047671; Thu, 23 Jun 2011 21:21:16 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.16.7]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5NKLCiN025126; Thu, 23 Jun 2011 21:21:12 +0100 Message-Id: <201106232021.p5NKLCiN025126@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Jun 2011 21:21:06 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4DF930D2.3050108@informatik.uni-tuebingen.de> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <4DF930D2.3050108@informatik.uni-tuebingen.de> 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: 23 Jun 2011 20:21:16.0995 (UTC) FILETIME=[1B299930:01CC31E3] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:21:21 -0000 Michael, The order you suggest is the logical structure one would expect for a solution document, leading from problem to solution. However, this doc describes the problem and the benefits of a solution that is a given (taken from abstract-mech). The solution is not intended to be derived from the problem statement. I have written a doc about re-ECN in the past that digs deeper and deeper into problem after problem in order to give the logic for why the particular solution was chosen. But that's not the purpose of this doc. It's not explaining the solution, it's just introducing it where necessary for context. Bob At 23:23 15/06/2011, Michael Menth wrote: >Hi Bob, hi John, > >I believe the draft contains all relevant ideas. Maybe the order of >the ideas could be changed a bit to shorten the text. Then there >would be more room to explain the figure in more detail. What about >the following order? > >multiplexing = power of the internet >what's congestion >what's the problem with current traffic management to avoid congestion >what's needed to solve the problem >what's the idea of ConEx >Explanation of the figure >ConEx is generative technology >new traffic management technologies based on conex may achieve >* transparency >* app neutrality >* not overconstrained >... >purpose of this document and maybe structure > >Best wishes, > > Michael > >Am 15.06.2011 23:39, schrieb John Leslie: >>Michael Menth wrote: >>>>>>>I like this text about conex. However, I am not sure if one can >>>>>>>fully follow if one doesn't have the "conex background". >> Yesterday I started a word-smithing pass, and asked Michael for >>clarification about some text he proposed. >> >> Today the day-job caught up with me. :^( >> >> Nonetheless, I think it worth posting my wordsmithing. It rewords >>most of Bob's text "to ease the readers' task" (including simpler >>sentence structure, avoiding some emotion-laden terms, and moving some >>follow-up details closer to the first mention); and it specifically >>includes some of Michael's text (wordsmithed as well). >> >> If I may suggest: posting "I prefer's text" really isn't >>helpful without adding a "because" clause. >> >> I reworked the Figure to have time consistently move downward. >> >> No doubt it could me shortened more -- this is still early in the >>wordsmithing passes. >> >>------------------------------- cut here ------------------------------- >>The power of Internet technology comes from multiplexing shared >>capacity with packets rather than circuits. Network operators aim >>to provide sufficicent capacity, but when too much packet load >>meets too little shared capacity, congestion results. >> >>Congestion may appear as increased delay, ECN [RFC3168] marking, >>or dropped packets. Internet Congestion Control depends upon a >>feedback loop where the receiving endpoint detects such signs, >>feeds this detection back to the sending endpoint, and the sender >>reduces the sending rate. >> >>The purpose of this document is to motivate a new congestion >>exposure (ConEx) field at the IP layer. The idea is to extend >>the feedback to a complete loop, such that the sender marks as >>'Congestion Expected' the level of congestion reported to it in >>the next packet(s) it sends. >> >>With this information, IP-layer network nodes can use this as input >>to traffic management. >> >> +---------+ +-----------+ +---------+ >> |Transport| | Congested | |Transport| >> | Sender | | Network | | Receiver| >> | |=Data=Path==>| Device |======Data=Path=====>| | >> | | | |-Congestion-Signal-->|-->+ | >> | | . . | | | >> | +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+ | >> | | | . . | | >> | | | | | | | >> | | |=Data=Path==>| |======Data=Path=====>| | >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+ | >> | | . . | | | >> | | . . |(ignored)| >> | | | | | | >> +---------+ +-----------+ +---------+ >> >> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >> >>This document serves as the entry point to the set of ConEx >>documentation, giving the 'why' rather than the 'how'. A companion >>document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. >> >>Current traffic management solutions are not effective at managing >>congestion, since they limit a user's traffic based on the wrong >>quantities. Volume caps and/or rate limitations may not be strict >>enough in case of congestion, while in the absence of congestion they >>constrain the end systems to a mediocre capability. If the network >>operator tries to improve this mediocre capability, the traffic >>management is no longer application-neutral and frequently obscures >>the very problem network operators sought to fix. >> >>Traffic management solutions could work so much better with feedback >>about congestion at the IP layer: access rates could be constrained >>when necessary and high bitrates could be allowed at other times. >>Congestion exposure (ConEx) aims to expose exactly that information >>to all IP nodes on a flow's path. >> >>By having the sender ConEx-mark packets, the network operator sees >>the congestion along the path of that flow one round-trip-time ago. >>Thus the network operator can leave the task of balancing bandwidth >>demands to well-behaved end-systems, while still having the tools to >>control traffic from end-systems which don't respond appropriately >>to congestion signals. >> >>Network operators won't need to identify specific applications, >>because the same information which applications should use to manage >>congestion will be visible to network operators: thus it will be >>clear whether applications (considered as a group) are responding >>appropriately to congestion. >> >>Because ConEx information is added explicitly at the IP layer, it is >>visible to provider and consumer alike. Therefore traffic contracts >>or acceptable use policies can be based on a metric that is >>transparent to both parties and is sufficient to manage traffic >>without extra non-transparent wriggle-room and caveats. >> >>The IP layer is intended to enable new applications and behaviours >>to work over all existing and new lower-layer technologies. ConEx >>is a generative technology in this vein, with a range of potential >>uses. >> >>In summary, ConEx is designed to make it simple to have traffic >>management which is transparent, neutral, and not over-constrained. >>Although it is not our place to require traffic management to meet >>those characteristics, this should be the simplest service to provide >>(and should reduce support costs). >>------------------------------- cut here ------------------------------- > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Fri Jun 24 05:48:08 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BDC11E80D3 for ; Fri, 24 Jun 2011 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1X17s0U6DWd for ; Fri, 24 Jun 2011 05:48:07 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9B11E8081 for ; Fri, 24 Jun 2011 05:48:07 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 13:48:05 +0100 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, 24 Jun 2011 13:48:05 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1308919691451; Fri, 24 Jun 2011 13:48:11 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.82.242]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5OCm2o1028757; Fri, 24 Jun 2011 13:48:03 +0100 Message-Id: <201106241248.p5OCm2o1028757@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Jun 2011 10:15:04 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <7.1.0.9.2.20110616130637.08397a38@bt.com> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <7.1.0.9.2.20110616130637.08397a38@bt.com> 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: 24 Jun 2011 12:48:05.0433 (UTC) FILETIME=[F6244290:01CC326C] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 12:48:08 -0000 John, At 13:19 16/06/2011, Bob Briscoe wrote: >To: John Leslie >From: Bob Briscoe >Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text >Cc: Michael Menth , ConEx IETF >list > >John, > >Thanks for this. I'll try to use as much as I can. I've only managed >to respond inline to a few paras, as I have to rush to a mtg... > >...rest will follow later. > >At 22:39 15/06/2011, John Leslie wrote: >> >>------------------------------- cut here ------------------------------- [jumping to halfway thru where I left off commenting a few days ago...] >>Current traffic management solutions are not effective at managing >>congestion, since they limit a user's traffic based on the wrong >>quantities. Volume caps and/or rate limitations may not be strict >>enough in case of congestion, while in the absence of congestion they >>constrain the end systems to a mediocre capability. If the network >>operator tries to improve this mediocre capability, the traffic >>management is no longer application-neutral and frequently obscures >>the very problem network operators sought to fix. I like the first part (based on Michael's suggestion), but I don't understand what was implicit in your mind during the last sentence. There's no intrinsic reason why improving a mediochre capability will lead to non-app-neutrality. Also, what is the stuff about "obscuring the problem" hinting at? Anyway, don't sweat this last sentence. I want to use Michael's whole contribution, because he spelled it out in simple baby-steps for the reader, which was good. >>Traffic management solutions could work so much better with feedback >>about congestion at the IP layer: access rates could be constrained >>when necessary and high bitrates could be allowed at other times. >>Congestion exposure (ConEx) aims to expose exactly that information >>to all IP nodes on a flow's path. I don't want to lose the part about satisfying operator's main concern for control. I want to make it clear is about a reasonable compromise: "Traffic management ought to ... satisfying the main concern of network operators; to control traffic from some users ..." I'll weave this back in somehow. See what you think when I post it later. >>By having the sender ConEx-mark packets, the network operator sees >>the congestion along the path of that flow one round-trip-time ago. ConEx isn't meant to be an RTT late (anyway 1 RTT is TCP-specific, RTCP feedback might be 20 RTTs behind). ConEx represents the expectation, ie at any instant ConEx has signalled at least as much as actual congestion. But explaining this needs to be deferred to the next section on concepts. >>Thus the network operator can leave the task of balancing bandwidth >>demands to well-behaved end-systems, while still having the tools to >>control traffic from end-systems which don't respond appropriately >>to congestion signals. I hope you agree that the following change would give a more appropriate impression of the intent in the reader's mind: s/...end-systems which don't respond appropriately to congestion signals./ /...sites that excessively contribute to congestion./ Reasoning: 1) I'd rather not make it seem to be about identifying traffic from specific end-systems, which is nearly the same as specific flows. It's about the traffic coming in to a network from a site, whether that's one machine, a home network or an enterprise. 2) Not responding appropriately to congestion is only one of the reasons for an excessive contribution to congestion. The other main reason is sending loads of traffic during congestion (even if every source responds appropriately to that congestion). We should explain how congestion-volume correctly counts up the 'harm' from either of these behaviours. However, this dual role will need careful explanation, so it needs to be in the Concepts section not here. For the Introduction, let's just use words that are general enough not to contradict what we will say later. >>Network operators won't need to identify specific applications, >>because the same information which applications should use to manage >>congestion will be visible to network operators: thus it will be >>clear whether applications (considered as a group) are responding >>appropriately to congestion. Again, responding to congestion is only half the story. >>Because ConEx information is added explicitly at the IP layer, it is >>visible to provider and consumer alike. Therefore traffic contracts >>or acceptable use policies can be based on a metric that is >>transparent to both parties and is sufficient to manage traffic >>without extra non-transparent wriggle-room and caveats. Yes, the addition of "non-transparent" makes the link back to transparency clearer. Nonetheless, given the word transparent is not well understood by some (e.g. Michael's comments) I suggested: s/a metric that is transparent to both.../ /a metric that is open and transparent to both.../ >>The IP layer is intended to enable new applications and behaviours >>to work over all existing and new lower-layer technologies. ConEx >>is a generative technology in this vein, with a range of potential >>uses. >> >>In summary, ConEx is designed to make it simple to have traffic >>management which is transparent, neutral, and not over-constrained. >>Although it is not our place to require traffic management to meet >>those characteristics, this should be the simplest service to provide >>(and should reduce support costs). >>------------------------------- cut here ------------------------------- OK. Many of these are useful re-phrasings. I will now produce a new Intro based on these, and the other earlier comments. Cheers Bob >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Fri Jun 24 06:06:23 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031A221F850C for ; Fri, 24 Jun 2011 06:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKBQxtiABejG for ; Fri, 24 Jun 2011 06:06:22 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9E721F84CE for ; Fri, 24 Jun 2011 06:06:22 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 14:06:21 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 14:06:20 +0100 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 1308920787447; Fri, 24 Jun 2011 14:06:27 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.82.242]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5OD6JuV028830 for ; Fri, 24 Jun 2011 14:06:19 +0100 Message-Id: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Jun 2011 14:06:16 +0100 To: ConEx IETF list From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 24 Jun 2011 13:06:20.0825 (UTC) FILETIME=[830BD090:01CC326F] Subject: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 13:06:23 -0000 Folks, Does this ASCII art float your boat? I've introduced two big arrows containing congestion signals, so that it is clearer that the two forward congestion signals are in the same flows of packets, not separate flows. Notice I've replaced 'Path' with 'Flow', so it is meant to represent the signals being carried within a flow of packets, rather than the path of nodes the flows traverse. This is also a test of whether it remains readable using different client's renderings (different line spacings can break up diagonals made of forward and backslashes, but I've tested the two main spacings and they look OK). Bob ,---------. ,---------. |Transport| |Transport| | Sender | |Receiver | | | /|___________________________________________| | | ,-<---------------Returned-Congestion-Signals--<--------. | | | |/ | | | | | |\ Transport Layer Feedback Flow | | | | | | \ ___________________________________________| | | | | | \| | | | | | | ,-----------. | | | | | |_____________| |______________|\ | | | | | | | | \ | | | | | | IP layer | | Data Flow \ | | | | | | | | \ | | | | | | |(Congested)| \ | | | | | | | Network | \| | | | | | | Device | /| | | | | | | |--Congestion-Signals--->-' | | | | | | / | | | `----------->--(new)-IP-layer-ConEx-Signals-------->| | | |_____________| |______________ / | | | | | | |/ | | `---------' `-----------' `---------' Figure 1: Where the ConEx Protocol Fits in the Internet Architecture ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Fri Jun 24 06:19:06 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09C811E80A6 for ; Fri, 24 Jun 2011 06:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGltk4SFIivW for ; Fri, 24 Jun 2011 06:19:06 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 6516F11E809B for ; Fri, 24 Jun 2011 06:19:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 577D7526F; Fri, 24 Jun 2011 15:18:58 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSnUPN29Uj5V; Fri, 24 Jun 2011 15:18:54 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 925AA5131; Fri, 24 Jun 2011 15:18:54 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id A972211BF475; Fri, 24 Jun 2011 15:18:53 +0200 (CEST) Message-ID: <4E048EBC.4020805@informatik.uni-tuebingen.de> Date: Fri, 24 Jun 2011 15:18:52 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bob Briscoe References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> In-Reply-To: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 13:19:06 -0000 Hi Bob, looks good to me, too. I like it. Just one thing: the pillars say "transport sender/receiver" This lets me think that information is exchanged on the transport layer. But in fact, conex info is carried on the IP layer while feedback information is carried on the transport layer. This should be reflected somehow in the both pillars at the edges of the picture. Best wishes, Michael Am 24.06.2011 15:06, schrieb Bob Briscoe: > Folks, > > Does this ASCII art float your boat? > > I've introduced two big arrows containing congestion signals, so that > it is clearer that the two forward congestion signals are in the same > flows of packets, not separate flows. > > Notice I've replaced 'Path' with 'Flow', so it is meant to represent > the signals being carried within a flow of packets, rather than the > path of nodes the flows traverse. > > This is also a test of whether it remains readable using different > client's renderings (different line spacings can break up diagonals > made of forward and backslashes, but I've tested the two main spacings > and they look OK). > > Bob > > > ,---------. ,---------. > |Transport| |Transport| > | Sender | |Receiver | > | | /|___________________________________________| | > | ,-<---------------Returned-Congestion-Signals--<--------. | > | | |/ | | | > | | |\ Transport Layer Feedback Flow | | | > | | | \ ___________________________________________| | | > | | | \| | | | > | | | ,-----------. | | | > | | |_____________| |______________|\ | | | > | | | | | \ | | | > | | | IP layer | | Data Flow \ | | | > | | | | | \ | | | > | | | |(Congested)| \ | | | > | | | | Network | \| | | > | | | | Device | /| | | > | | | | |--Congestion-Signals--->-' | > | | | | | / | | > | `----------->--(new)-IP-layer-ConEx-Signals-------->| | > | |_____________| |______________ / | | > | | | | |/ | | > `---------' `-----------' `---------' > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From richard_woundy@cable.comcast.com Fri Jun 24 06:34:38 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070CF11E8076 for ; Fri, 24 Jun 2011 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faYk8lv9wrev for ; Fri, 24 Jun 2011 06:34:37 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD48228013 for ; Fri, 24 Jun 2011 06:34:36 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.42075085; Fri, 24 Jun 2011 07:38:08 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Fri, 24 Jun 2011 09:34:27 -0400 From: "Woundy, Richard" To: Michael Menth , Bob Briscoe Thread-Topic: [conex] Diag for draft-ietf-conex-concepts-uses Thread-Index: AQHMMm+H0J5Z2CfBmkKYaHz4gIV9ZJTMwLQA///AxWA= Date: Fri, 24 Jun 2011 13:34:25 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135A013C@PACDCEXMB05.cable.comcast.com> References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <4E048EBC.4020805@informatik.uni-tuebingen.de> In-Reply-To: <4E048EBC.4020805@informatik.uni-tuebingen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 13:34:38 -0000 > This lets me think that information is exchanged on the transport layer.= =20 >But in fact, conex info is carried on the IP layer while feedback informat= ion is carried on the transport layer. But the arrows in the diagram are labeled "IP layer Data Flow" and "Transpo= rt Layer Feedback Flow". Isn't that sufficient? -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of M= ichael Menth Sent: Friday, June 24, 2011 9:19 AM To: Bob Briscoe Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses Hi Bob, looks good to me, too. I like it. Just one thing: the pillars say "transport sender/receiver" This lets me think that information is exchanged on the transport layer.=20 But in fact, conex info is carried on the IP layer while feedback=20 information is carried on the transport layer. This should be reflected somehow in the both pillars at the edges of the=20 picture. Best wishes, Michael Am 24.06.2011 15:06, schrieb Bob Briscoe: > Folks, > > Does this ASCII art float your boat? > > I've introduced two big arrows containing congestion signals, so that=20 > it is clearer that the two forward congestion signals are in the same=20 > flows of packets, not separate flows. > > Notice I've replaced 'Path' with 'Flow', so it is meant to represent=20 > the signals being carried within a flow of packets, rather than the=20 > path of nodes the flows traverse. > > This is also a test of whether it remains readable using different=20 > client's renderings (different line spacings can break up diagonals=20 > made of forward and backslashes, but I've tested the two main spacings=20 > and they look OK). > > Bob > > > ,---------. ,---------. > |Transport| |Transport| > | Sender | |Receiver | > | | /|___________________________________________| | > | ,-<---------------Returned-Congestion-Signals--<--------. | > | | |/ | | | > | | |\ Transport Layer Feedback Flow | | | > | | | \ ___________________________________________| | | > | | | \| | | | > | | | ,-----------. | | | > | | |_____________| |______________|\ | | | > | | | | | \ | | | > | | | IP layer | | Data Flow \ | | | > | | | | | \ | | | > | | | |(Congested)| \ | | | > | | | | Network | \| | | > | | | | Device | /| | | > | | | | |--Congestion-Signals--->-' | > | | | | | / | | > | `----------->--(new)-IP-layer-ConEx-Signals-------->| | > | |_____________| |______________ / | | > | | | | |/ | | > `---------' `-----------' `---------' > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Fri Jun 24 06:48:01 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FB121F8469 for ; Fri, 24 Jun 2011 06:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDkaj84UhM7y for ; Fri, 24 Jun 2011 06:48:00 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 1C16A21F8442 for ; Fri, 24 Jun 2011 06:47:59 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 14:47:58 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 14:47:58 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1308923284772; Fri, 24 Jun 2011 14:48:04 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.82.242]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5ODltTX028998; Fri, 24 Jun 2011 14:47:57 +0100 Message-Id: <201106241347.p5ODltTX028998@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Jun 2011 14:47:23 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4E048EBC.4020805@informatik.uni-tuebingen.de> References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <4E048EBC.4020805@informatik.uni-tuebingen.de> 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: 24 Jun 2011 13:47:58.0626 (UTC) FILETIME=[53DA0020:01CC3275] Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 13:48:01 -0000 Michael, I think I will leave it as transport sender/receiver. This is an argument that could run and run. So I'd rather stop it now, as it is merely a question of definitions. * Some would say that the transport receiver reads info from the IP layer and (with ConEx) the transport sender writes info into the IP layer. * Some would say that the functions of drop, ECN marking and ConEx Policy are transport functions, so they say there is a rudimentary transport layer even on basic network equipment that only does tail-drop (e.g. John Day's "Patterns in Network Architecture; A Return to Fundamentals"). * Some would say the transport sender requests the IP sender to write into the IP header (which I think is your view). * Yet another objection is that the application might implement these functions. I have taken the view that Congestion Control and ConEx are transport-related functions. Bob At 14:18 24/06/2011, Michael Menth wrote: >Hi Bob, > >looks good to me, too. I like it. > >Just one thing: the pillars say "transport sender/receiver" >This lets me think that information is exchanged on the transport >layer. But in fact, conex info is carried on the IP layer while >feedback information is carried on the transport layer. > >This should be reflected somehow in the both pillars at the edges of >the picture. > >Best wishes, > > Michael > > > >Am 24.06.2011 15:06, schrieb Bob Briscoe: >>Folks, >> >>Does this ASCII art float your boat? >> >>I've introduced two big arrows containing congestion signals, so >>that it is clearer that the two forward congestion signals are in >>the same flows of packets, not separate flows. >> >>Notice I've replaced 'Path' with 'Flow', so it is meant to >>represent the signals being carried within a flow of packets, >>rather than the path of nodes the flows traverse. >> >>This is also a test of whether it remains readable using different >>client's renderings (different line spacings can break up diagonals >>made of forward and backslashes, but I've tested the two main >>spacings and they look OK). >> >>Bob >> >> >> ,---------. ,---------. >> |Transport| |Transport| >> | Sender | |Receiver | >> | | /|___________________________________________| | >> | ,-<---------------Returned-Congestion-Signals--<--------. | >> | | |/ | | | >> | | |\ Transport Layer Feedback Flow | | | >> | | | \ ___________________________________________| | | >> | | | \| | | | >> | | | ,-----------. | | | >> | | |_____________| |______________|\ | | | >> | | | | | \ | | | >> | | | IP layer | | Data Flow \ | | | >> | | | | | \ | | | >> | | | |(Congested)| \ | | | >> | | | | Network | \| | | >> | | | | Device | /| | | >> | | | | |--Congestion-Signals--->-' | >> | | | | | / | | >> | `----------->--(new)-IP-layer-ConEx-Signals-------->| | >> | |_____________| |______________ / | | >> | | | | |/ | | >> `---------' `-----------' `---------' >> >> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >> >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Fri Jun 24 07:08:52 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D92411E808C for ; Fri, 24 Jun 2011 07:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ3OR+KLgWnn for ; Fri, 24 Jun 2011 07:08:51 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 495B9228006 for ; Fri, 24 Jun 2011 07:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E34E552C0; Fri, 24 Jun 2011 16:08:45 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xim1V33HyUKV; Fri, 24 Jun 2011 16:08:41 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 132DD51DB; Fri, 24 Jun 2011 16:08:40 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 619EA1EE0C66; Fri, 24 Jun 2011 16:08:40 +0200 (CEST) Message-ID: <4E049A67.20805@informatik.uni-tuebingen.de> Date: Fri, 24 Jun 2011 16:08:39 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bob Briscoe References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <4E048EBC.4020805@informatik.uni-tuebingen.de> <201106241347.p5ODltTX028998@bagheera.jungle.bt.co.uk> In-Reply-To: <201106241347.p5ODltTX028998@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:08:52 -0000 Hi Bob, I'm not debating the transport aspect, this is there for sure, too. However, we want to implement conex in IP because every node on the path should be able to see the conex information. Or is this assumption no longer valid? And this should be reflected, otherwise the picture may be misleading. Regards, Michael Am 24.06.2011 15:47, schrieb Bob Briscoe: > Michael, > > I think I will leave it as transport sender/receiver. > > This is an argument that could run and run. So I'd rather stop it now, > as it is merely a question of definitions. > > * Some would say that the transport receiver reads info from the IP > layer and (with ConEx) the transport sender writes info into the IP > layer. > > * Some would say that the functions of drop, ECN marking and ConEx > Policy are transport functions, so they say there is a rudimentary > transport layer even on basic network equipment that only does > tail-drop (e.g. John Day's "Patterns in Network Architecture; A Return > to Fundamentals"). > > * Some would say the transport sender requests the IP sender to write > into the IP header (which I think is your view). > > * Yet another objection is that the application might implement these > functions. > > I have taken the view that Congestion Control and ConEx are > transport-related functions. > > > Bob > > At 14:18 24/06/2011, Michael Menth wrote: >> Hi Bob, >> >> looks good to me, too. I like it. >> >> Just one thing: the pillars say "transport sender/receiver" >> This lets me think that information is exchanged on the transport >> layer. But in fact, conex info is carried on the IP layer while >> feedback information is carried on the transport layer. >> >> This should be reflected somehow in the both pillars at the edges of >> the picture. >> >> Best wishes, >> >> Michael >> >> >> >> Am 24.06.2011 15:06, schrieb Bob Briscoe: >>> Folks, >>> >>> Does this ASCII art float your boat? >>> >>> I've introduced two big arrows containing congestion signals, so >>> that it is clearer that the two forward congestion signals are in >>> the same flows of packets, not separate flows. >>> >>> Notice I've replaced 'Path' with 'Flow', so it is meant to represent >>> the signals being carried within a flow of packets, rather than the >>> path of nodes the flows traverse. >>> >>> This is also a test of whether it remains readable using different >>> client's renderings (different line spacings can break up diagonals >>> made of forward and backslashes, but I've tested the two main >>> spacings and they look OK). >>> >>> Bob >>> >>> >>> ,---------. >>> ,---------. >>> |Transport| >>> |Transport| >>> | Sender | >>> |Receiver | >>> | | >>> /|___________________________________________| | >>> | >>> ,-<---------------Returned-Congestion-Signals--<--------. | >>> | | |/ | >>> | | >>> | | |\ Transport Layer Feedback Flow | >>> | | >>> | | | \ ___________________________________________| >>> | | >>> | | | \| | >>> | | >>> | | | ,-----------. | >>> | | >>> | | |_____________| |______________|\ | >>> | | >>> | | | | | \ | >>> | | >>> | | | IP layer | | Data Flow \ | >>> | | >>> | | | | | \ | >>> | | >>> | | | |(Congested)| \ | >>> | | >>> | | | | Network | \| >>> | | >>> | | | | Device | /| >>> | | >>> | | | | >>> |--Congestion-Signals--->-' | >>> | | | | | / >>> | | >>> | >>> `----------->--(new)-IP-layer-ConEx-Signals-------->| | >>> | |_____________| |______________ / >>> | | >>> | | | | |/ >>> | | >>> `---------' `-----------' >>> `---------' >>> >>> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >>> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Faculty of Science >> Department of Computer Science >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505 >> fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de >> http://www-kn.informatik.uni-tuebingen.de > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From john@jlc.net Fri Jun 24 08:20:12 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21849E800A for ; Fri, 24 Jun 2011 08:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.038 X-Spam-Level: X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdoUGBN5ekVQ for ; Fri, 24 Jun 2011 08:20:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5F9E8004 for ; Fri, 24 Jun 2011 08:20:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CF77033C25; Fri, 24 Jun 2011 11:20:11 -0400 (EDT) Date: Fri, 24 Jun 2011 11:20:11 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110624152011.GF76722@verdi> References: <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:20:12 -0000 Bob Briscoe wrote: > > Marcelo, Nandita, > > Pls give guidance as wg chairs, so we don't write text you will later > ask us to remove... This isn't a fair question. WGCs aren't authors; nor are they editors: they call consensus. > We (the editors) are having trouble with the requirement not to > describe mechanism in conex-concepts-uses. People on the list seem to > agree that some very high level description of ConEx mechanism is > necessary in order to make sense of following text. The question is, > where to draw the line. That will have to wait for an editors' pass -- then see what various WG participants think. (That's why we pay the editors those big bucks!) > Certainly, it is good discipline to be able to describe the problem > without describing the mechanism of a solution. But concepts-uses > covers more than the problem. It also has to describe central > concepts. If we describe central concepts without some degree of > mechanism description, it's going to be one of those weird documents > that commits to nothing and becomes content-free. I agree with Bob, here. > The list seems happy that something pitched at the level of how the > ConEx charter describes the mechanism is fine (plus a picture a bit > like the first one in abstract-mech). But we seem to need more to > support later text. For example: > > 1/ Timing > In the Concepts section (the new name for section 2 on Definitions) > we plan to explain what we mean by 'expected congestion' by talking > about the sender starting off signalling a conservative expectation > of congestion when it has no info about the path, then once it gets > e2e transport feedback, it can continually re-insert the feedback > into the IP layer as its expectation of congestion. IMHO, that could go in a definition of "expected congestion"; or the definition could merely state that the "expected congestion" signaled before the first RTT completes is application-dependent. > 2/ Headers > I prefer to say ConEx info is put in packet headers at the IP layer. > Some argue we should just say "at the IP layer" without mentioning > headers. I think it's clearer to mention packet headers. IMHO, this is a distinction without a difference. I'd tend to leave it out in a concepts/uses document, but I see no reason to call it inappropriate. > My logic is that the rule against speaking about mechanism is > primarily designed to avoid prejudging later mechanism documents. > However, if abstract-mech is already settled on a decision, and if > describing it in concepts-uses is essential background to explain a > concept, I would rather just do that, than dance around in abstract-land. IMHO, abstract-mech should not be considered "settled" -- not because _I_ mean to challenge anything in it, but because our charter prevents sending it to the IESG for approval until after they act on the concepts document. > Otherwise readers might imagine we could be talking about backward > ICMP messages or something, and get confused. IMHO, the less said about mechanism in concepts/uses, the less we're inviting such confusion. :^( (YMMV, of course.) -- John Leslie From john@jlc.net Fri Jun 24 08:27:35 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544EF11E80E0 for ; Fri, 24 Jun 2011 08:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.085 X-Spam-Level: X-Spam-Status: No, score=-106.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jaBMuFhzXmN for ; Fri, 24 Jun 2011 08:27:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B178111E8096 for ; Fri, 24 Jun 2011 08:27:34 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 89C6433C21; Fri, 24 Jun 2011 11:27:34 -0400 (EDT) Date: Fri, 24 Jun 2011 11:27:34 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110624152734.GA56541@verdi> References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:27:35 -0000 Bob Briscoe wrote: > > ,---------. ,---------. > |Transport| |Transport| > | Sender | |Receiver | > | | /|___________________________________________| | > | ,-<---------------Returned-Congestion-Signals--<--------. | > | | |/ | | | > | | |\ Transport Layer Feedback Flow | | | > | | | \ ___________________________________________| | | > | | | \| | | | > | | | ,-----------. | | | > | | |_____________| |______________|\ | | | > | | | | | \ | | | > | | | IP layer | | Data Flow \ | | | > | | | | | \ | | | > | | | |(Congested)| \ | | | > | | | | Network | \| | | > | | | | Device | /| | | > | | | | |--Congestion-Signals--->-' | > | | | | | / | | > | `----------->--(new)-IP-layer-ConEx-Signals-------->| | > | |_____________| |______________ / | | > | | | | |/ | | > `---------' `-----------' `---------' > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture This is a big improvement. The only thing which jumps out at me is the reader asking, "How is a Transport Sender different from any other kind of Sender?" However, there is the occupational hazard of becoming so familiar with a diagram that we can no longer see it with fresh eyes. I'd like to see some explanatory text near the diagram -- though I don't at first blush see any absolute need... -- John Leslie From carlberg@g11.org.uk Fri Jun 24 08:32:40 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD7111E809B for ; Fri, 24 Jun 2011 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uanVqa4aB99Z for ; Fri, 24 Jun 2011 08:32:39 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id BA7A811E808C for ; Fri, 24 Jun 2011 08:32:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=0KFh+rpR7JpOOqxP+FpMMHw5QLGZScV0MgztpT8QQrg2zPNrXZ5FnEVpu9BBKNwW9GpEjfAlEgbisy/GFes3aUXhmtkgRmak+stJoz0Z3BW1TaJV+P4wSA/R/0ECY7kS; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:60425 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Qa8Mv-0003z9-S3; Fri, 24 Jun 2011 15:32:30 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <20110624152011.GF76722@verdi> Date: Fri, 24 Jun 2011 11:32:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <20110624152011.GF76722@verdi> To: John Leslie X-Mailer: Apple Mail (2.1084) 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 list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:32:40 -0000 John, >> Pls give guidance as wg chairs, so we don't write text you will later=20= >> ask us to remove... >=20 > This isn't a fair question. WGCs aren't authors; nor are they = editors: > they call consensus. I would very respectfully, but strongly disagree. WGCs are meant to be = participants -- both as individuals and as chairs. One will notice that = chairs in other groups will qualify their statements to the list as = "speaking as an individual" or "with my working group chair hat on" so = that the audience knows the context of the statements. I would very much appreciate seeing some input from the chairs on the = list since this is where all the official work is being done. I'm = concerned about last minute statements made at meetings that cause a = fair amount of work (equating to valuable time by authors) to be = discarded. =20 cheers, -ken From bob.briscoe@bt.com Fri Jun 24 08:41:55 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B1711E80FF for ; Fri, 24 Jun 2011 08:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHx4kTpMG1T5 for ; Fri, 24 Jun 2011 08:41:55 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1191711E808C for ; Fri, 24 Jun 2011 08:41:54 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 16:41:53 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 16:41:53 +0100 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 1308930120288; Fri, 24 Jun 2011 16:42:00 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.176.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5OFfofX029400; Fri, 24 Jun 2011 16:41:50 +0100 Message-Id: <201106241541.p5OFfofX029400@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Jun 2011 16:41:48 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20110624152734.GA56541@verdi> References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <20110624152734.GA56541@verdi> 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: 24 Jun 2011 15:41:53.0492 (UTC) FILETIME=[3DBFC940:01CC3285] Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:41:55 -0000 John, Thanks - we have some progress. To an Ethernet person, a sender is an IP router. To an MPLS person, a sender can be an IP router. Transport sender means a sender with a transport layer on it. It could be the source, a Web proxy, a TCP proxy, or a router sending on a SCTP connection to a management system. Bob At 16:27 24/06/2011, John Leslie wrote: >Bob Briscoe wrote: > > > > ,---------. ,---------. > > |Transport| |Transport| > > | Sender | |Receiver | > > | | /|___________________________________________| | > > | ,-<---------------Returned-Congestion-Signals--<--------. | > > | | |/ | | | > > | | |\ Transport Layer Feedback Flow | | | > > | | | \ ___________________________________________| | | > > | | | \| | | | > > | | | ,-----------. | | | > > | | |_____________| |______________|\ | | | > > | | | | | \ | | | > > | | | IP layer | | Data Flow \ | | | > > | | | | | \ | | | > > | | | |(Congested)| \ | | | > > | | | | Network | \| | | > > | | | | Device | /| | | > > | | | | |--Congestion-Signals--->-' | > > | | | | | / | | > > | `----------->--(new)-IP-layer-ConEx-Signals-------->| | > > | |_____________| |______________ / | | > > | | | | |/ | | > > `---------' `-----------' `---------' > > > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > This is a big improvement. The only thing which jumps out at me is >the reader asking, "How is a Transport Sender different from any other >kind of Sender?" > > However, there is the occupational hazard of becoming so familiar >with a diagram that we can no longer see it with fresh eyes. I'd like >to see some explanatory text near the diagram -- though I don't at >first blush see any absolute need... > >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Fri Jun 24 08:46:38 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C711E8110 for ; Fri, 24 Jun 2011 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfHOESpkCl1V for ; Fri, 24 Jun 2011 08:46:37 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 898F411E80E3 for ; Fri, 24 Jun 2011 08:46:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 614AC52C0; Fri, 24 Jun 2011 17:46:36 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Sr4ASdP+kH; Fri, 24 Jun 2011 17:46:33 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 531BC5241; Fri, 24 Jun 2011 17:46:33 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id C287F1EE23D5; Fri, 24 Jun 2011 17:46:32 +0200 (CEST) Message-ID: <4E04B14E.1030903@informatik.uni-tuebingen.de> Date: Fri, 24 Jun 2011 17:46:22 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bob Briscoe References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <20110624152734.GA56541@verdi> <201106241541.p5OFfofX029400@bagheera.jungle.bt.co.uk> In-Reply-To: <201106241541.p5OFfofX029400@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:46:38 -0000 Hi Bob, Am 24.06.2011 17:41, schrieb Bob Briscoe: > John, > > Thanks - we have some progress. > > To an Ethernet person, a sender is an IP router. > To an MPLS person, a sender can be an IP router. > > Transport sender means a sender with a transport layer on it. It could > be the source, a Web proxy, a TCP proxy, or a router sending on a SCTP > connection to a management system. This is the missing explanation. You mean that the sender and receiver must have some transport layer capability. That's ok, but must be explicitly stated in the accompanying text. I got it wrong. Regards, Michael > > > Bob > > At 16:27 24/06/2011, John Leslie wrote: >> Bob Briscoe wrote: >> > >> > ,---------. >> ,---------. >> > |Transport| >> |Transport| >> > | Sender | >> |Receiver | >> > | | >> /|___________________________________________| | >> > | >> ,-<---------------Returned-Congestion-Signals--<--------. | >> > | | |/ | >> | | >> > | | |\ Transport Layer Feedback Flow | >> | | >> > | | | \ ___________________________________________| >> | | >> > | | | \| | >> | | >> > | | | ,-----------. | >> | | >> > | | |_____________| |______________|\ | >> | | >> > | | | | | \ | >> | | >> > | | | IP layer | | Data Flow \ | >> | | >> > | | | | | \ | >> | | >> > | | | |(Congested)| \ | >> | | >> > | | | | Network | \| >> | | >> > | | | | Device | /| >> | | >> > | | | | >> |--Congestion-Signals--->-' | >> > | | | | | / >> | | >> > | >> `----------->--(new)-IP-layer-ConEx-Signals-------->| | >> > | |_____________| |______________ / >> | | >> > | | | | |/ >> | | >> > `---------' `-----------' >> `---------' >> > >> > Figure 1: Where the ConEx Protocol Fits in the Internet >> Architecture >> >> This is a big improvement. The only thing which jumps out at me is >> the reader asking, "How is a Transport Sender different from any other >> kind of Sender?" >> >> However, there is the occupational hazard of becoming so familiar >> with a diagram that we can no longer see it with fresh eyes. I'd like >> to see some explanatory text near the diagram -- though I don't at >> first blush see any absolute need... >> >> -- >> John Leslie > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From toby@moncaster.com Sat Jun 25 13:31:09 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB211E80BE for ; Sat, 25 Jun 2011 13:31:09 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD6nga150AWt for ; Sat, 25 Jun 2011 13:31:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9014211E807F for ; Sat, 25 Jun 2011 13:31:08 -0700 (PDT) Received: from TobysHP (host81-156-178-213.range81-156.btcentralplus.com [81.156.178.213]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Mdo4b-1Qxtgd3CDV-00QHbm; Sat, 25 Jun 2011 22:31:07 +0200 From: "Toby Moncaster" To: "'Michael Menth'" , "'Bob Briscoe'" References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <20110624152734.GA56541@verdi> <201106241541.p5OFfofX029400@bagheera.jungle.bt.co.uk> <4E04B14E.1030903@informatik.uni-tuebingen.de> In-Reply-To: <4E04B14E.1030903@informatik.uni-tuebingen.de> Date: Sat, 25 Jun 2011 21:31:02 +0100 Message-ID: <002001cc3376$cd6cf850$6846e8f0$@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: AcwyhepPglCzp6xHR82pyZ+J1G0iXQA8JqAQ Content-Language: en-gb X-Provags-ID: V02:K0:aZ5pKE9+ff6flf87Z5Uzsrsvz1IhraFmpnB7f3NQNia Cq58zAugQJpiEDZfwWXWx4mtEbayZUKn0OGF1m/6RLY87bxCtm L+j2FnZsYC3iNERx03to+f2esLY7LbJvqXe9gM0P6u5jB2HpMK OTxRSpLmc694mkVcwdcLFRtMHBdgXL5735YEJUJcmG9djBcatl BavlrsN2jecatmzYwwSkWg9aOVWXQnp4VtEu3vbsCs= Cc: 'ConEx IETF list' Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 20:31:09 -0000 I agree with Michael (and John) - the diagram is good (and pretty impressive for ASCII art), but you need to make sure you explain what is meant by transport tx/rx as the term could confuse folks. It should be easy enough to incorporate the explanation in the text near the diagram... Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Michael Menth > Sent: 24 June 2011 16:46 > To: Bob Briscoe > Cc: ConEx IETF list > Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses > > Hi Bob, > > Am 24.06.2011 17:41, schrieb Bob Briscoe: > > John, > > > > Thanks - we have some progress. > > > > To an Ethernet person, a sender is an IP router. > > To an MPLS person, a sender can be an IP router. > > > > Transport sender means a sender with a transport layer on it. It > could > > be the source, a Web proxy, a TCP proxy, or a router sending on a > SCTP > > connection to a management system. > This is the missing explanation. You mean that the sender and receiver > must have some transport layer capability. That's ok, but must be > explicitly stated in the accompanying text. I got it wrong. > > Regards, > > Michael > > > > > > > > Bob > > > > At 16:27 24/06/2011, John Leslie wrote: > >> Bob Briscoe wrote: > >> > > >> > ,---------. > >> ,---------. > >> > |Transport| > >> |Transport| > >> > | Sender | > >> |Receiver | > >> > | | > >> /|___________________________________________| | > >> > | > >> ,-<---------------Returned-Congestion-Signals--<--------. | > >> > | | |/ | > >> | | > >> > | | |\ Transport Layer Feedback Flow | > >> | | > >> > | | | \ ___________________________________________| > >> | | > >> > | | | \| | > >> | | > >> > | | | ,-----------. | > >> | | > >> > | | |_____________| |______________|\ | > >> | | > >> > | | | | | \ | > >> | | > >> > | | | IP layer | | Data Flow \ | > >> | | > >> > | | | | | \ | > >> | | > >> > | | | |(Congested)| \ | > >> | | > >> > | | | | Network | \| > >> | | > >> > | | | | Device | /| > >> | | > >> > | | | | > >> |--Congestion-Signals--->-' | > >> > | | | | | / > >> | | > >> > | > >> `----------->--(new)-IP-layer-ConEx-Signals-------->| | > >> > | |_____________| |______________ / > >> | | > >> > | | | | |/ > >> | | > >> > `---------' `-----------' > >> `---------' > >> > > >> > Figure 1: Where the ConEx Protocol Fits in the Internet > >> Architecture > >> > >> This is a big improvement. The only thing which jumps out at me > is > >> the reader asking, "How is a Transport Sender different from any > other > >> kind of Sender?" > >> > >> However, there is the occupational hazard of becoming so familiar > >> with a diagram that we can no longer see it with fresh eyes. I'd > like > >> to see some explanatory text near the diagram -- though I don't at > >> first blush see any absolute need... > >> > >> -- > >> John Leslie > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Sat Jun 25 13:40:05 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE611E80CB for ; Sat, 25 Jun 2011 13:40:05 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBsFdIZOdynA for ; Sat, 25 Jun 2011 13:40:04 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7D02811E80BE for ; Sat, 25 Jun 2011 13:40:04 -0700 (PDT) Received: from TobysHP (host81-156-178-213.range81-156.btcentralplus.com [81.156.178.213]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LxLzO-1RgLWv3oss-016Fja; Sat, 25 Jun 2011 22:39:20 +0200 From: "Toby Moncaster" To: "'ken carlberg'" , "'John Leslie'" References: <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <20110624152011.GF76722@verdi> In-Reply-To: Date: Sat, 25 Jun 2011 21:39:15 +0100 Message-ID: <002101cc3377$f35b6640$da1232c0$@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: Acwyg/Y5d+2IYMHeT4C0svkBsy3qFwA8tngg Content-Language: en-gb X-Provags-ID: V02:K0:xTzHDpkgXPWIt/vsXjjgc2Tc2wh40pieDIW3N372sWF zKIFX4QwTGlyxmrJv648RlPeTZ/ekDI0679P86OKRSOUgBZUvJ 3KmfyEdT5QDwGYoEHwYeU+cKTT7wbUsU9cUU7ZhF9JKutddGFD W0oAoDlfn9K69YDsqOuGHaQDCqqR9G6MqXejajtWtL3D+55zcd BPxTwboMPNU0pI+8JbCBhekUhiLGvFS0IJ2JOZlmCk= Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 20:40:05 -0000 I am not sure these are such contradictory views. WGCs are first and foremost responsible for getting the WG charter items completed to the satisfaction of the IESG. This involves calling consensus in the WG, but can also involve cajoling authors, coercing reviewers or challenging dissenters (sorry, couldn't resist the alliterative list...) However WGCs are also members of the WG and have a legitimate interest in the work of the WG. At times that may put them personally at odds with the consensus of the WG, and at such times they need to make it crystal clear whether they are expressing a view as an individual or as a WGC. They may decide the conflict is such that they have to defer to the other WGC (one of the main arguments for having co-chairs). What is certain is that there is currently insufficient communication on the ML from the chairs. I for one would be keen to avoid ever seeing a repeat of the situation in Prague where the chairs suddenly turn on some of the document authors without previously having expressed their concerns either on or off list... Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of ken carlberg > Sent: 24 June 2011 16:33 > To: John Leslie > Cc: 'ConEx IETF list' > Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? > > John, > > >> Pls give guidance as wg chairs, so we don't write text you will > later > >> ask us to remove... > > > > This isn't a fair question. WGCs aren't authors; nor are they > editors: > > they call consensus. > > I would very respectfully, but strongly disagree. WGCs are meant to be > participants -- both as individuals and as chairs. One will notice > that chairs in other groups will qualify their statements to the list > as "speaking as an individual" or "with my working group chair hat on" > so that the audience knows the context of the statements. > > I would very much appreciate seeing some input from the chairs on the > list since this is where all the official work is being done. I'm > concerned about last minute statements made at meetings that cause a > fair amount of work (equating to valuable time by authors) to be > discarded. > > cheers, > > -ken > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From menth@informatik.uni-tuebingen.de Sat Jun 25 14:31:34 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7741111E8101 for ; Sat, 25 Jun 2011 14:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M19iqReUx6SF for ; Sat, 25 Jun 2011 14:31:33 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 9AB0411E807F for ; Sat, 25 Jun 2011 14:31:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8496D52D2; Sat, 25 Jun 2011 23:31:27 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7scyI1QaQPB; Sat, 25 Jun 2011 23:31:21 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id A38235274; Sat, 25 Jun 2011 23:31:21 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id ADCE31EFC703; Sat, 25 Jun 2011 23:31:20 +0200 (CEST) Message-ID: <4E0653A0.7060600@informatik.uni-tuebingen.de> Date: Sat, 25 Jun 2011 23:31:12 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Woundy, Richard" References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <4E048EBC.4020805@informatik.uni-tuebingen.de> <1CA25301D2219F40B3AA37201F0EACD1135A013C@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1135A013C@PACDCEXMB05.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 21:31:34 -0000 Am 24.06.2011 15:34, schrieb Woundy, Richard: >> This lets me think that information is exchanged on the transport layer. >> But in fact, conex info is carried on the IP layer while feedback information is carried on the transport layer. > But the arrows in the diagram are labeled "IP layer Data Flow" and "Transport Layer Feedback Flow". Isn't that sufficient? That's not the problem. It's not clear why it is necessary to mention that the endpoints are transport sender/receiver. If it is important, then explain briefly in the accompanying text, if it is not important, then drop the label! Probably you mean that the sender must be a transport endpoint to find out about congestion from the receiver and then conex-marks packets on the IP-layer. Something along these lines should be said in the text. Then it's clear what the "transport sender/receiver" labels mean. Regards, Michael > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Michael Menth > Sent: Friday, June 24, 2011 9:19 AM > To: Bob Briscoe > Cc: ConEx IETF list > Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses > > Hi Bob, > > looks good to me, too. I like it. > > Just one thing: the pillars say "transport sender/receiver" > This lets me think that information is exchanged on the transport layer. > But in fact, conex info is carried on the IP layer while feedback > information is carried on the transport layer. > > This should be reflected somehow in the both pillars at the edges of the > picture. > > Best wishes, > > Michael > > > > Am 24.06.2011 15:06, schrieb Bob Briscoe: >> Folks, >> >> Does this ASCII art float your boat? >> >> I've introduced two big arrows containing congestion signals, so that >> it is clearer that the two forward congestion signals are in the same >> flows of packets, not separate flows. >> >> Notice I've replaced 'Path' with 'Flow', so it is meant to represent >> the signals being carried within a flow of packets, rather than the >> path of nodes the flows traverse. >> >> This is also a test of whether it remains readable using different >> client's renderings (different line spacings can break up diagonals >> made of forward and backslashes, but I've tested the two main spacings >> and they look OK). >> >> Bob >> >> >> ,---------. ,---------. >> |Transport| |Transport| >> | Sender | |Receiver | >> | | /|___________________________________________| | >> | ,-<---------------Returned-Congestion-Signals--<--------. | >> | | |/ | | | >> | | |\ Transport Layer Feedback Flow | | | >> | | | \ ___________________________________________| | | >> | | | \| | | | >> | | | ,-----------. | | | >> | | |_____________| |______________|\ | | | >> | | | | | \ | | | >> | | | IP layer | | Data Flow \ | | | >> | | | | | \ | | | >> | | | |(Congested)| \ | | | >> | | | | Network | \| | | >> | | | | Device | /| | | >> | | | | |--Congestion-Signals--->-' | >> | | | | | / | | >> | `----------->--(new)-IP-layer-ConEx-Signals-------->| | >> | |_____________| |______________ / | | >> | | | | |/ | | >> `---------' `-----------' `---------' >> >> Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >> >> >> ________________________________________________________________ >> Bob Briscoe, BT Innovate& Design >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From karagian@cs.utwente.nl Sat Jun 25 15:55:50 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804F111E80A0 for ; Sat, 25 Jun 2011 15:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o67oCTsplT1f for ; Sat, 25 Jun 2011 15:55:49 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7146A11E8096 for ; Sat, 25 Jun 2011 15:55:49 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p5PMsOWn002117; Sun, 26 Jun 2011 00:54:25 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 25 Jun 2011 22:55:49 +0000 To: "Bob Briscoe" Date: Sat, 25 Jun 2011 22:55:49 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <8WNfnIBH.1309042549.4323470.karagian@ewi.utwente.nl> In-Reply-To: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 26 Jun 2011 00:54:36 +0200 (MEST) Cc: conex@ietf.org Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 22:55:50 -0000 Hi Bob, Sorry for the delay on sending comments! I have a comment regarding the following paragraph: > With ConEx there is no need for the network provider to identify > specific applications or behaviours at the flow level, because the > relevant bulk congestion information is revealed at the network > layer. Also, because ConEx information is added explicitly at the IP > layer, it is visible to provider and consumer alike. Therefore > traffic contracts or acceptable use policies can be based on a metric > that is transparent to both parties and is sufficient to manage > traffic without extra non-transparent wriggle-room and caveats. In the paragrah above it is mentioned that the network provider to identify specific applications or behaviours at the flow level, because the relevant bulk congestion information is revealed at the network layer. However, according to RFC 6077, in multi-domain scenarios, due to the non-cooperative nature of multi-domain environments, it seems unlikely that network flow state could be avoided (up to a certain extend) given the network's per-packet flow rate instructions that would need to be compared against variations in the actual flow rate, which is inherently not a per-packet metric. For RFC 6077, see: http://www.rfc-editor.org/rfc/rfc6077.txt Is it possible to explain in the draft how the congestion control related issues associated with multi-domain scenarios discussed in RFC 6077 are solved/worked out? Best regards, Georgios On 6/14/2011, "Bob Briscoe" wrote: >ConEx folks, > >After the last IETF in Prague, we agreed to work on a revised >draft-ietf-conex-concepts-uses. We're planning on using a lot of the >text as is, but we suggested that the Introduction needed a complete >re-write. Below is our joint proposal. > >Please bash. > >Rationale for this Introduction: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >* The main change is a shift to the main target use-case in the body >of the document: traffic management, leaving defining congestion etc >to the definitions and concepts section (section 2). >* Introduce enough of the solution to allow the reader to grasp the main log= ic. >* Introduce one primary use and mention there are others - to keep >focused but hint at breadth. >* Start to weave in some benefits bullet points (transparency, neutrality). >* Hint at controversies like the over-provisioning issue in the first >para, but leave addressing this to later, when we can go into the >subject properly. > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >1. Introduction > > The power of Internet technology comes from multiplexing shared > capacity with packets rather than circuits. Network operators > usually provide sufficient capacity, but whenever too much packet > load meets too little shared capacity, congestion results. > Congestion appears as either increased delay, missing packets or > packets explicitly marked with ECN [RFC3168]. The classic Internet > architecture is arranged so that receivers detect such signs of > congestion and feed them back end-to-end. Then, ideally, most > senders reduce their rate in response. > > The purpose of this document is to motivate a new congestion exposure > (ConEx) field at the IP layer. The idea is to add a third pass to > the feedback loop so that the sender can relay congestion information > back into the internetwork layer, exposing the level of congestion > the sender expects packets to experience along their whole path > (Figure 1). Then certain network nodes can use this new information > at the IP layer, for example as input to traffic management. > > ,---------. ,---------. > |Transport| |Transport| > | Sender | |Receiver | > | |<=3D=3DFeedback=3DPath=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<| | > | ,---|<--Transport Layer returned Congestion Signal-<|<--. | > | | | | | | > | | | | | | > | | | ,-----------. | | | > | | | |(Congested)| | | | > | | |>=3DData=3DPath=3D>| Network |>=3D=3D=3D=3D=3DData=3DPath= =3D=3D=3D=3D=3D>| | | > | | | | Device |>-Congestion-Signal->|---' | > | | | `-----------' | | > | `-->|>---------(new) IP layer ConEx Signal--------->| | > | | (Carried in Data Packet Headers) | | > `---------' `---------' > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > This document serves as the entry point to the set of ConEx > documentation, giving the 'why' rather than the 'how'. A companion > document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. > > The main aim of ConEx is to support evolution of alternatives to the > proliferation of traffic management solutions that are over- > constraining, non-transparent and often not application-neutral. > Traffic management ought to be able to leave end systems free to > choose how to behave without undue interference, while simultaneously > satisfying the main concern of network operators; to control traffic > from some users that excessively limits the freedoms of others. > > Freedoms only actually collide when shared capacity becomes > congested--when a link is full so that a greater share for one user > would necessarily leave less for someone else. Current traffic > management solutions typically limit volume or bit-rate in order to > reduce the likelihood of congestion--limiting one thing in the hope > it might limit another. However, there is no real need to count > volume that is sent when there is no congestion, and there is no real > need to limit bit-rate when there is no congestion. > > ConEx markings on packets add the missing information network > operators need to get a handle on congestion itself. Then they can > directly limit and control traffic based on how much it contributes > to congestion and leave traffic unconstrained if it doesn't cause > congestion. The idea is for the operator to be able to count and > control the bulk volume or bit-rate of packets marked for congestion > and disregard packets not contributing to congestion. > > With ConEx there is no need for the network provider to identify > specific applications or behaviours at the flow level, because the > relevant bulk congestion information is revealed at the network > layer. Also, because ConEx information is added explicitly at the IP > layer, it is visible to provider and consumer alike. Therefore > traffic contracts or acceptable use policies can be based on a metric > that is transparent to both parties and is sufficient to manage > traffic without extra non-transparent wriggle-room and caveats. > > In summary, ConEx is designed to make it simple to do traffic > management that is transparent, neutral and not over-constrained. > Although there is no implication that network operators ought to > provide such an unconstrained, transparent, neutral service, it > certainly should not be impossible and ideally it should be the > simplest service to provide. > > The IP layer is intended to engender new applications and behaviours > and to work over all existing and new lower layer technologies. > ConEx is a generative technology in this vein, with a range of > potential uses. This document focuses initially on traffic > management before widening out to introduce some additional important > uses for ConEx as well as brifly mentioning a few others. >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > >Bob Briscoe & Rich Woundy > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Sun Jun 26 00:35:42 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC22521F84E8 for ; Sun, 26 Jun 2011 00:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0ioxGkecQYi for ; Sun, 26 Jun 2011 00:35:41 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61621F84E7 for ; Sun, 26 Jun 2011 00:35:40 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (35.50.22.95.dynamic.jazztel.es [95.22.50.35]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 72C5771280C; Sun, 26 Jun 2011 09:35:32 +0200 (CEST) Message-ID: <4E06E142.5090300@it.uc3m.es> Date: Sun, 26 Jun 2011 09:35:30 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> In-Reply-To: <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18222.003 Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 07:35:43 -0000 Hi, speaking as a WG co-chair below... El 23/06/11 17:06, Bob Briscoe escribió: > Marcelo, Nandita, > > Pls give guidance as wg chairs, so we don't write text you will later > ask us to remove... > > We (the editors) are having trouble with the requirement not to > describe mechanism in conex-concepts-uses. People on the list seem to > agree that some very high level description of ConEx mechanism is > necessary in order to make sense of following text. The question is, > where to draw the line. > so, having the use cases separated from the mechanism description is an artifact from the wh charter creation process. Nevertheless, there are plenty of cases where use cases or applicability statements are described in different documents than the actual mechanisms, so, that should be feasible. The wierd thing is our case is that we are supposed to deliver the use case document before the mechanism description. I agree that in order to understand the use cases the reader needs to understand the actual mechanism. So, i think we have several options here: 1- Since we have a mature mechanism document, we can simply rely on it to describe the mechanism and assume that reader will read the abstract mechanism before reading the use case document. We can even include a normative reference and even if we ship the use case document to the IESG first, both docs will have to be published together. 2- We can copy part of the mechanism defined in the mechanism draft into the use case draft, in order to make it more self contained. The problem with this is that these two docs needs to be highly coordinated, in order to avoid contradictions between the docs. 3- We can decide to merge the 2 documents. That would require us to talk to the iesg and convice them that this is the best approach, but if the WG feels this is the way to go, we can try it. So, I think we can do any of these 3. So far we have been oscilating between 1 and 2, which falls within what is specified in the charter, which i guess would make our progress easier. That being said, it is up to the wg to choose whic appraoch is better (or to suggest other approaches) Speaking as an individual now, i believe that is easier and more practical to go for option 1. Assume that the reader has read the abstract mechanism and heavily reference it and talk about the mechanism as described in there. We should ship them both toghter to the IESG, even if they don't consider the mechanism one for publication until the use case has been through. Regards, marcelo > Certainly, it is good discipline to be able to describe the problem > without describing the mechanism of a solution. But concepts-uses > covers more than the problem. It also has to describe central > concepts. If we describe central concepts without some degree of > mechanism description, it's going to be one of those weird documents > that commits to nothing and becomes content-free. For example... > > > The list seems happy that something pirtched at the level of how the > ConEx charter describes the mechanism is fine (plus a picture a bit > like the first one in abstract-mech). But we seem to need more to > support later text. For example: > > 1/ Timing > In the Concepts section (the new name for section 2 on Definitions) we > plan to explain what we mean by 'expected congestion' by talking about > the sender starting off signalling a conservative expectation of > congestion when it has no info about the path, then once it gets e2e > transport feedback, it can continually re-insert the feedback into the > IP layer as its expectation of congestion. > > 2/ Headers > I prefer to say ConEx info is put in packet headers at the IP layer. > Some argue we should just say "at the IP layer" without mentioning > headers. I think it's clearer to mention packet headers. > > My logic is that the rule against speaking about mechanism is > primarily designed to avoid prejudging later mechanism documents. > However, if abstract-mech is already settled on a decision, and if > describing it in concepts-uses is essential background to explain a > concept, I would rather just do that, than dance around in abstract-land. > > Otherwise readers might imagine we could be talking about backward > ICMP messages or something, and get confused. > > > > Bob > > At 19:15 17/06/2011, Toby Moncaster wrote: > > >> > -----Original Message----- >> > From: Bob Briscoe [mailto:bob.briscoe@bt.com] >> > Sent: 17 June 2011 18:38 >> > To: Toby Moncaster >> > Cc: 'John Leslie'; 'ConEx IETF list' >> > Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text >> > >> > TOby, >> > >> > Deliberately responding to the middle of the thread, inline... >> > >> > At 17:43 16/06/2011, Toby Moncaster wrote: >> > >> > > > -----Original Message----- >> > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> > Behalf >> > > > Of John Leslie >> > > > Sent: 16 June 2011 14:54 >> > > > To: Bob Briscoe >> > > > Cc: ConEx IETF list >> > > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro >> text >> > > > >> > > > Bob Briscoe wrote: >> > > > > At 22:39 15/06/2011, John Leslie wrote: >> > > > >> >> > > > >> The purpose of this document is to motivate a new congestion >> > > > >> exposure (ConEx) field at the IP layer. The idea is to extend >> > > > >> the feedback to a complete loop, such that the sender marks as >> > > > >> 'Congestion Expected' the level of congestion reported to it in >> > > > >> the next packet(s) it sends. >> > > > > >> > > > > This removes the pointers to where we are in the diag (that >> > Michael >> > > > > asked me to add, and I agreed would help lost readers). >> > > > >> > > > Hmm... not sure what you mean... In any case, the reader would >> > have >> > > > forgotten this text by the time s/he gets to the diagram. >> > > >> > >Although the diagram could refer back. Personally, when I come across >> > text >> > >like this and there is a diagram, I feel the text should point to the >> > >diagram, but should be clear enough to work for people that don't >> > think in >> > >pictures... >> > > >> > > > >> > > > > I don't think 'complete loop' is useful as people already think >> > of it >> > > > > as a complete loop before ConEx. This also might make newbies >> > think >> > > > > that the router that generates the congestion signal also always >> > > > > reads the ConEx signal. >> > > > >> > > > I agree "loop" isn't the right word. >> > > >> > >Especially it isn't right as ConEx should work in transports where >> > there is >> > >no congestion feedback. >> > > >> > >We do need to make it clear that no router needs to read the ConEx >> > signal >> > >(though any router should be able to if it so wishes) >> > >> > We don't even need to say the parenthesis. >> >> Indeed. I just wanted to make it clear to people reading this thread -- >> there are still people that believe ConEx requires every device to >> understand it >> >> > >> > >> > > > >> > > > > "...to add a third pass to the feedback loop" says exactly what >> > is >> > > > > happening, doesn't it? >> > > > >> > > > Perhaps in your mind... I don't think it conveys that to the >> > reader, >> > > > though. >> > > >> > >Surely at that point ConEx is feed-forward, not feedback? >> Otherwise it >> > might >> > >sound like you expect the receiver to acknowledge how much ConEx >> > signal it >> > >saw (which you might want as some sort of nonce for data validity, >> but >> > isn't >> > >part of the core ConEx signal). >> > > >> > >I will try and think of a clearer way to express this. I know this >> > won't >> > >just slot straight into the text, but how about: >> > > >> > >"Congestion control currently relies on the receiver informing the >> > sender of >> > >any congestion it has seen. The sender then responds to such >> > congestion >> > >indications in order to reduce the congestion. ConEx requires the >> > sender to >> > >state how much congestion it expects to cause by sending a >> "congestion >> > >experienced" signal with any data it sends. This ConEx signal travels >> > >unchanged through the network to the receiver and can be seen at any >> > >intermediate routers or devices that choose to read it." >> > >> > That's pretty good. But again, I would deconfuse by simply saying: >> > s/intermediate routers or devices/IP layer devices/ >> >> That is clearer and covers all sensible possibilities. >> >> > >> > >> > > > >> > > > We might try something more in line with "in both directions". >> > > > I think the point is that the added congestion signal needs to >> > travel >> > > > in the same direction the data experiencing congestion traveled, >> > and >> > > > needs to follow the whole path. >> > > >> > >And the SAME path! i.e. it shouldn't be taking the slow path in >> > routers. >> > >> > Fast/slow path is mechanism. >> >> OK, fair point. >> >> > >> > Same path isn't absolutely necessary, as long as it's typical. Like >> > packets of a flow, they can change path, but you don't want them to >> > have to be pinned ONLY to one path. So I wouldn't bring path up here >> > (this is introduction). >> >> OK you're right that we don't want too much detail in an >> introduction. There >> might be a need to discuss these sort of details in another document >> (perhaps as an appendix?) >> >> > >> > >> > >> > > > >> > > > >> +---------+ +-----------+ >> +--- >> > ---- >> > > > --+ >> > > > >> |Transport| | Congested | >> > > > |Transport| >> > > > >> | Sender | | Network | | >> > > > Receiver| >> > > > >> | |=Data=Path==>| Device |======Data=Path=====>| >> > > > | >> > > > >> | | | |-Congestion-Signal-->|-- >> > >+ >> > > > | >> > > > >> | | . . | >> > | >> > > > | >> > > > >> | +<--|<--Transport-.---Layer---.<--Congestion >> Signal-|<-- >> > + >> > > > | >> > > > >> | | | . . | >> > > > | >> > > > >> | | | | | | >> > > > | >> > > > >> | | |=Data=Path==>| |======Data=Path=====>| >> > > > | >> > > > >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-- >> > >+ >> > > > | >> > > > >> | | . . | >> > | >> > > > | >> > > > >> | | . . >> > > > |(ignored)| >> > > > >> | | | | | >> > > > | >> > > > >> +---------+ +-----------+ >> +--- >> > ---- >> > > > --+ >> > > > >> >> > > > >> Figure 1: Where the ConEx Protocol Fits in the Internet >> > > > Architecture >> > > > > >> > > > > We obviously have two different implicit y axes. You're thinking >> > of >> > > > > time down the page, I'm thinking of layering. I think this shows >> > we >> > > > > need to label both (layers and time). >> > > > >> > > > Good catch! My Transport Layer Congestion Signal needs "=", not >> > "-". >> > > > " >> > > > " | +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ >> > > > | >> > > > >> > > > The reader expects time to be the downward Y-axis. Making it >> > > > anything >> > > > else will tend to confuse the reader. >> > >> > I think John means "confuse readers who think like John" >> > My suggestion was to label the axis, so people don't have to guess. >> > Then we don't have to continue this discussion. >> >> Diagrams are always hard because people see them differently. >> >> > >> > If we discuss what "expected" congestion is, that should be under >> > section 2, which we plan to re-title as Concepts, rather than just >> > Definitions. >> >> Yes, fair enough - expected needs actual explanation >> >> > >> > That's also where I promised David we would discuss the timescale >> > subtelties of the congestion-volume metric. >> > >> > >> > >I actually think BOTH diagrams are useful. Bob's diagram makes it >> > clear >> > >where ConEx fits into the existing congestion feedback architecture, >> > while >> > >John's diagram is useful for showing the delay in the signal. I would >> > >suggest Bob's diagram is better for the introduction, but I would be >> > keen to >> > >have John's time-based diagram included somewhere (as it will make >> > more >> > >sense to those people who are used to such diagrams). >> > >> > People expect a protocol timing diag to have diagonal lines. >> >> Agreed, that is a mechanism thing >> >> > >> > Personally I don't think we should try to discuss protocol timing in >> > concepts-uses. It's virtually impossible to talk about it in a >> > mechanism-neutral way. >> >> I am actually not 100% sure you can avoid all mechanism and protocol >> details >> whilst still having a concepts and use cases document that makes >> sense. I >> know we have to ensure that the majority of mechanism is in >> abstract-mech, >> but you may need a bit in order to explain the concept >> >> > >> > We have this in abstract-mech (I can't remember if it's in the >> > published version or the next rev that has my updates and is sitting >> > waiting for Matt to add his). >> > >> > >> > > > >> > > > > I wouldn't say 'ignored' because that could imply everything >> else >> > > > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is >> used. >> > > > >> > > > I agree "ignored" isn't the right word. Perhaps "not used". >> > > >> > >"not used" is better, since there might be a need to have a check >> > later on >> > >(as I mentioned above), or at least paranoid end-systems might >> want to >> > be >> > >able to check it! However that still has an implication that other >> > things do >> > >"use" the signal. >> > >> > As I said once, saying "not used", "ignored" or anything here is >> > pre-judging how ConEx is used by the receiver. This was deliberately >> > left blank. >> > >> >> OK, I have now looked back at your diagram and agree that it is much >> clearer >> without this >> >> > >> > > > >> > > > > I agree we could remove 'in data packet headers' because it's >> > > > > mechanism, but on balance I thought it might undertanding help >> > > > > to leave it in. >> > > > >> > > > I don't agree. It's pure mechanism -- while "IP-layer" steers >> > clear >> > > > of mechanism. >> > > >> > >Agree with John - in data packet headers is mechanism. The key point >> > here >> > >(surely) is that the signal must be visible to devices that want to >> > see it? >> > >That sort of implies packet header, but only if you assume a packet- >> > oriented >> > >IP layer (and I personally think ConEx can apply in other >> > architectures in >> > >future) >> > >> > Er, can we stay a little grounded here. This is the IETF, not the >> > "Inter-Galactic Packet Network Standards Force". >> >> I know! >> >> > >> > For the IETF, "in the IP layer" means the same as "in IP packet >> > headers". Because there is only IP payload and IP headers in the IP >> > layer. And we're not putting ConEx in the payload. >> >> So let's say "in the IP layer". As soon as you explicitly state in the >> packet header you will get shouts of "mechanism" (though this is >> perhaps a >> case in point where you will find it hard to excise all mechanism >> from this >> document) >> >> > >> > In concepts-uses we are only not talking about mechanism in order not >> > to pre-judge later decisions. There is no alternative on the table >> > other than signalling ConEx in data packet headers, so we can assume >> > it. If we abstract for abstraction's sake, no-one will understand. >> >> I don't see how not specifying where the conex info is carried is >> going to >> confuse? >> >> One key driver for keeping the mechanism out of this draft was that I >> got >> told off by the WGCs for having mechanism in an earlier version... >> >> Toby >> >> > >> > >> > Bob >> > >> > >> > >Toby >> > > >> > > >> > > > >> > > > > have to go... more later... >> > > > >> > > > Thanks. >> > > > >> > > > -- >> > > > John Leslie >> > > > _______________________________________________ >> > > > conex mailing list >> > > > conex@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/conex >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From bob.briscoe@bt.com Sun Jun 26 01:46:26 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1582E11E8074 for ; Sun, 26 Jun 2011 01:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT0bc1Te4d7l for ; Sun, 26 Jun 2011 01:46:25 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id EA3C711E8072 for ; Sun, 26 Jun 2011 01:46:24 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 09:46:23 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 09:46:23 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1309077982261; Sun, 26 Jun 2011 09:46:22 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.176.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5Q8kK0k009929; Sun, 26 Jun 2011 09:46:20 +0100 Message-Id: <201106260846.p5Q8kK0k009929@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 25 Jun 2011 08:53:59 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4E04B14E.1030903@informatik.uni-tuebingen.de> References: <201106241306.p5OD6JuV028830@bagheera.jungle.bt.co.uk> <20110624152734.GA56541@verdi> <201106241541.p5OFfofX029400@bagheera.jungle.bt.co.uk> <4E04B14E.1030903@informatik.uni-tuebingen.de> 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: 26 Jun 2011 08:46:23.0548 (UTC) FILETIME=[872BB7C0:01CC33DD] Cc: ConEx IETF list Subject: Re: [conex] Diag for draft-ietf-conex-concepts-uses X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 08:46:26 -0000 Michael, 'Transport sender/receiver is used widely in IETF documents. I would rather not disrupt the flow of the introduction to define every word and phrase. When anyone first comes across these two words together, surely the only possible meaning is the sender or receiver at the transport layer. Your concern was different: that the ConEx protocol appears at the IP layer. This is not a problem because higher layers always determine what appears on the wire at lower layers. That's how everything always works. We cannot include a whole book's worth of text about general Internet architecture within a document on ConEx. Bob At 16:46 24/06/2011, Michael Menth wrote: >Hi Bob, > >Am 24.06.2011 17:41, schrieb Bob Briscoe: >>John, >> >>Thanks - we have some progress. >> >>To an Ethernet person, a sender is an IP router. >>To an MPLS person, a sender can be an IP router. >> >>Transport sender means a sender with a transport layer on it. It >>could be the source, a Web proxy, a TCP proxy, or a router sending >>on a SCTP connection to a management system. >This is the missing explanation. You mean that the sender and >receiver must have some transport layer capability. That's ok, but >must be explicitly stated in the accompanying text. I got it wrong. > >Regards, > > Michael > > >> >> >>Bob >> >>At 16:27 24/06/2011, John Leslie wrote: >>>Bob Briscoe wrote: >>> > >>> > ,---------. >>>,---------. >>> > |Transport| >>>|Transport| >>> > | Sender | >>>|Receiver | >>> > | | >>>/|___________________________________________| | >>> > | >>>,-<---------------Returned-Congestion-Signals--<--------. | >>> > | | |/ | >>>| | >>> > | | |\ Transport Layer Feedback Flow | >>>| | >>> > | | | \ ___________________________________________| >>>| | >>> > | | | \| | >>>| | >>> > | | | ,-----------. | >>>| | >>> > | | |_____________| |______________|\ | >>>| | >>> > | | | | | \ | >>>| | >>> > | | | IP layer | | Data Flow \ | >>>| | >>> > | | | | | \ | >>>| | >>> > | | | |(Congested)| \ | >>>| | >>> > | | | | Network | \| >>>| | >>> > | | | | Device | /| >>>| | >>> > | | | | >>>|--Congestion-Signals--->-' | >>> > | | | | | / >>>| | >>> > | >>>`----------->--(new)-IP-layer-ConEx-Signals-------->| | >>> > | |_____________| |______________ / >>>| | >>> > | | | | |/ >>>| | >>> > `---------' `-----------' >>>`---------' >>> > >>> > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture >>> >>> This is a big improvement. The only thing which jumps out at me is >>>the reader asking, "How is a Transport Sender different from any other >>>kind of Sender?" >>> >>> However, there is the occupational hazard of becoming so familiar >>>with a diagram that we can no longer see it with fresh eyes. I'd like >>>to see some explanatory text near the diagram -- though I don't at >>>first blush see any absolute need... >>> >>>-- >>>John Leslie >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >-- >Prof. Dr. habil. Michael Menth >University of Tuebingen >Faculty of Science >Department of Computer Science >Chair of Communication Networks >Sand 13, 72076 Tuebingen, Germany >phone: (+49)-7071/29-70505 >fax: (+49)-7071/29-5220 >mailto:menth@uni-tuebingen.de >http://www-kn.informatik.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Sun Jun 26 02:26:27 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5477A9E8043 for ; Sun, 26 Jun 2011 02:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBVIsxvlZYY4 for ; Sun, 26 Jun 2011 02:26:26 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8123E9E8004 for ; Sun, 26 Jun 2011 02:26:25 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 10:26:24 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 10:26:23 +0100 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 1309080382797; Sun, 26 Jun 2011 10:26:22 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.176.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5Q9QH2X010040; Sun, 26 Jun 2011 10:26:18 +0100 Message-Id: <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 26 Jun 2011 10:26:17 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4E06E142.5090300@it.uc3m.es> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 26 Jun 2011 09:26:23.0649 (UTC) FILETIME=[1DBE1110:01CC33E3] Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 09:26:27 -0000 Marcelo, Thanks for this. There's another option between your options 1 &=20 2, which I would like to argue for (and perhaps=20 this is what you were really thinking of): Option 1.5: Reference abstract-mech, but=20 summarise (rather than copy) anything=20 particularly relevant, so that concepts-uses is=20 self-contained enough to be read first. Reasoning: people don't want to read about a=20 mechanism if they don't know why it might be=20 useful. So we ought to make the 'why' doc the=20 recommended entry-point. Then if that convinces=20 them, they can read the 'how' doc for more details. I don't like pure option 1 (heavily reference=20 abstract-mech). If information elsewhere is=20 critical to the understanding of a doc, I believe=20 its poor writing style to use a bare reference to=20 the other doc without at least a brief summary of the concept the reader= needs. [Nonetheless, I admit this is going to get=20 unweildy, given concepts-uses has a section on=20 partial deployment. That's very hard to talk=20 about without extensive prior knowledge of the=20 mechanism. But let's at least try it and see.] Bob At 08:35 26/06/2011, marcelo bagnulo braun wrote: >Hi, > >speaking as a WG co-chair >below... > > >El 23/06/11 17:06, Bob Briscoe escribi=F3: >>Marcelo, Nandita, >> >>Pls give guidance as wg chairs, so we don't=20 >>write text you will later ask us to remove... >> >>We (the editors) are having trouble with the=20 >>requirement not to describe mechanism in=20 >>conex-concepts-uses. People on the list seem to=20 >>agree that some very high level description of=20 >>ConEx mechanism is necessary in order to make=20 >>sense of following text. The question is, where to draw the line. >so, having the use cases separated from the=20 >mechanism description is an artifact from the wh charter creation process. >Nevertheless, there are plenty of cases where=20 >use cases or applicability statements are=20 >described in different documents than the actual=20 >mechanisms, so, that should be feasible. >The wierd thing is our case is that we are=20 >supposed to deliver the use case document before the mechanism description. > >I agree that in order to understand the use=20 >cases the reader needs to understand the actual mechanism. > >So, i think we have several options here: > >1- Since we have a mature mechanism document, we=20 >can simply rely on it to describe the mechanism=20 >and assume that reader will read the abstract=20 >mechanism before reading the use case document.=20 >We can even include a normative reference and=20 >even if we ship the use case document to the=20 >IESG first, both docs will have to be published together. > >2- We can copy part of the mechanism defined in=20 >the mechanism draft into the use case draft, in=20 >order to make it more self contained. The=20 >problem with this is that these two docs needs=20 >to be highly coordinated, in order to avoid contradictions between the= docs. > >3- We can decide to merge the 2 documents. That=20 >would require us to talk to the iesg and convice=20 >them that this is the best approach, but if the=20 >WG feels this is the way to go, we can try it. > >So, I think we can do any of these 3. So far we=20 >have been oscilating between 1 and 2, which=20 >falls within what is specified in the charter,=20 >which i guess would make our progress easier. > >That being said, it is up to the wg to choose=20 >whic appraoch is better (or to suggest other approaches) > >Speaking as an individual now, i believe that is=20 >easier and more practical to go for option 1.=20 >Assume that the reader has read the abstract=20 >mechanism and heavily reference it and talk=20 >about the mechanism as described in there. We=20 >should ship them both toghter to the IESG, even=20 >if they don't consider the mechanism one for=20 >publication until the use case has been through. > >Regards, marcelo > > >>Certainly, it is good discipline to be able to=20 >>describe the problem without describing the=20 >>mechanism of a solution. But concepts-uses=20 >>covers more than the problem. It also has to=20 >>describe central concepts. If we describe=20 >>central concepts without some degree of=20 >>mechanism description, it's going to be one of=20 >>those weird documents that commits to nothing=20 >>and becomes content-free. For example... >> >> >>The list seems happy that something pirtched at=20 >>the level of how the ConEx charter describes=20 >>the mechanism is fine (plus a picture a bit=20 >>like the first one in abstract-mech). But we=20 >>seem to need more to support later text. For example: >> >>1/ Timing >>In the Concepts section (the new name for=20 >>section 2 on Definitions) we plan to explain=20 >>what we mean by 'expected congestion' by=20 >>talking about the sender starting off=20 >>signalling a conservative expectation of=20 >>congestion when it has no info about the path,=20 >>then once it gets e2e transport feedback, it=20 >>can continually re-insert the feedback into the=20 >>IP layer as its expectation of congestion. >> >>2/ Headers >>I prefer to say ConEx info is put in packet=20 >>headers at the IP layer. Some argue we should=20 >>just say "at the IP layer" without mentioning=20 >>headers. I think it's clearer to mention packet headers. >> >>My logic is that the rule against speaking=20 >>about mechanism is primarily designed to avoid=20 >>prejudging later mechanism documents. However,=20 >>if abstract-mech is already settled on a=20 >>decision, and if describing it in concepts-uses=20 >>is essential background to explain a concept, I=20 >>would rather just do that, than dance around in abstract-land. >> >>Otherwise readers might imagine we could be=20 >>talking about backward ICMP messages or something, and get confused. >> >> >> >>Bob >> >>At 19:15 17/06/2011, Toby Moncaster wrote: >> >> >>> > -----Original Message----- >>> > From: Bob Briscoe [mailto:bob.briscoe@bt.com] >>> > Sent: 17 June 2011 18:38 >>> > To: Toby Moncaster >>> > Cc: 'John Leslie'; 'ConEx IETF list' >>> > Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text >>> > >>> > TOby, >>> > >>> > Deliberately responding to the middle of the thread, inline... >>> > >>> > At 17:43 16/06/2011, Toby Moncaster wrote: >>> > >>> > > > -----Original Message----- >>> > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >>> > Behalf >>> > > > Of John Leslie >>> > > > Sent: 16 June 2011 14:54 >>> > > > To: Bob Briscoe >>> > > > Cc: ConEx IETF list >>> > > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro= text >>> > > > >>> > > > Bob Briscoe wrote: >>> > > > > At 22:39 15/06/2011, John Leslie wrote: >>> > > > >> >>> > > > >> The purpose of this document is to motivate a new congestion >>> > > > >> exposure (ConEx) field at the IP layer. The idea is to extend >>> > > > >> the feedback to a complete loop, such that the sender marks as >>> > > > >> 'Congestion Expected' the level of congestion reported to it in >>> > > > >> the next packet(s) it sends. >>> > > > > >>> > > > > This removes the pointers to where we are in the diag (that >>> > Michael >>> > > > > asked me to add, and I agreed would help lost readers). >>> > > > >>> > > > Hmm... not sure what you mean... In any case, the reader would >>> > have >>> > > > forgotten this text by the time s/he gets to the diagram. >>> > > >>> > >Although the diagram could refer back. Personally, when I come across >>> > text >>> > >like this and there is a diagram, I feel the text should point to the >>> > >diagram, but should be clear enough to work for people that don't >>> > think in >>> > >pictures... >>> > > >>> > > > >>> > > > > I don't think 'complete loop' is useful as people already think >>> > of it >>> > > > > as a complete loop before ConEx. This also might make newbies >>> > think >>> > > > > that the router that generates the congestion signal also always >>> > > > > reads the ConEx signal. >>> > > > >>> > > > I agree "loop" isn't the right word. >>> > > >>> > >Especially it isn't right as ConEx should work in transports where >>> > there is >>> > >no congestion feedback. >>> > > >>> > >We do need to make it clear that no router needs to read the ConEx >>> > signal >>> > >(though any router should be able to if it so wishes) >>> > >>> > We don't even need to say the parenthesis. >>> >>>Indeed. I just wanted to make it clear to people reading this thread -- >>>there are still people that believe ConEx requires every device to >>>understand it >>> >>> > >>> > >>> > > > >>> > > > > "...to add a third pass to the feedback loop" says exactly what >>> > is >>> > > > > happening, doesn't it? >>> > > > >>> > > > Perhaps in your mind... I don't think it conveys that to the >>> > reader, >>> > > > though. >>> > > >>> > >Surely at that point ConEx is feed-forward, not feedback? Otherwise= it >>> > might >>> > >sound like you expect the receiver to acknowledge how much ConEx >>> > signal it >>> > >saw (which you might want as some sort of nonce for data validity,= but >>> > isn't >>> > >part of the core ConEx signal). >>> > > >>> > >I will try and think of a clearer way to express this. I know this >>> > won't >>> > >just slot straight into the text, but how about: >>> > > >>> > >"Congestion control currently relies on the receiver informing the >>> > sender of >>> > >any congestion it has seen. The sender then responds to such >>> > congestion >>> > >indications in order to reduce the congestion. ConEx requires the >>> > sender to >>> > >state how much congestion it expects to cause by sending a= "congestion >>> > >experienced" signal with any data it sends. This ConEx signal travels >>> > >unchanged through the network to the receiver and can be seen at any >>> > >intermediate routers or devices that choose to read it." >>> > >>> > That's pretty good. But again, I would deconfuse by simply saying: >>> > s/intermediate routers or devices/IP layer devices/ >>> >>>That is clearer and covers all sensible possibilities. >>> >>> > >>> > >>> > > > >>> > > > We might try something more in line with "in both directions". >>> > > > I think the point is that the added congestion signal needs to >>> > travel >>> > > > in the same direction the data experiencing congestion traveled, >>> > and >>> > > > needs to follow the whole path. >>> > > >>> > >And the SAME path! i.e. it shouldn't be taking the slow path in >>> > routers. >>> > >>> > Fast/slow path is mechanism. >>> >>>OK, fair point. >>> >>> > >>> > Same path isn't absolutely necessary, as long as it's typical. Like >>> > packets of a flow, they can change path, but you don't want them to >>> > have to be pinned ONLY to one path. So I wouldn't bring path up here >>> > (this is introduction). >>> >>>OK you're right that we don't want too much detail in an introduction.= There >>>might be a need to discuss these sort of details in another document >>>(perhaps as an appendix?) >>> >>> > >>> > >>> > >>> > > > >>> > > > >> +---------+ +-----------+ >>>+--- >>> > ---- >>> > > > --+ >>> > > > >> |Transport| | Congested | >>> > > > |Transport| >>> > > > >> | Sender | | Network | | >>> > > > Receiver| >>> > > > >> | |=3DData=3DPath=3D=3D>| Device = |=3D=3D=3D=3D=3D=3DData=3DPath=3D=3D=3D=3D=3D>| >>> > > > | >>> > > > >> | | | |-Congestion-Signal-->|-- >>> > >+ >>> > > > | >>> > > > >> | | . . | >>> > | >>> > > > | >>> > > > >> | +<--|<--Transport-.---Layer---.<--Congestion= Signal-|<-- >>> > + >>> > > > | >>> > > > >> | | | . . | >>> > > > | >>> > > > >> | | | | | | >>> > > > | >>> > > > >> | | |=3DData=3DPath=3D=3D>| = |=3D=3D=3D=3D=3D=3DData=3DPath=3D=3D=3D=3D=3D>| >>> > > > | >>> > > > >> | +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-- >>> > >+ >>> > > > | >>> > > > >> | | . . | >>> > | >>> > > > | >>> > > > >> | | . . >>> > > > |(ignored)| >>> > > > >> | | | | | >>> > > > | >>> > > > >> +---------+ +-----------+ >>>+--- >>> > ---- >>> > > > --+ >>> > > > >> >>> > > > >> Figure 1: Where the ConEx Protocol Fits in the Internet >>> > > > Architecture >>> > > > > >>> > > > > We obviously have two different implicit y axes. You're thinking >>> > of >>> > > > > time down the page, I'm thinking of layering. I think this shows >>> > we >>> > > > > need to label both (layers and time). >>> > > > >>> > > > Good catch! My Transport Layer Congestion Signal needs "=3D",= not >>> > "-". >>> > > > " >>> > > > " | +<=3D=3D|<=3D=3DTransport=3D.=3D=3D=3DLayer=3D=3D=3D.<=3D= =3DCongestion=3DSignal=3D|<=3D=3D+ >>> > > > | >>> > > > >>> > > > The reader expects time to be the downward Y-axis. Making it >>> > > > anything >>> > > > else will tend to confuse the reader. >>> > >>> > I think John means "confuse readers who think like John" >>> > My suggestion was to label the axis, so people don't have to guess. >>> > Then we don't have to continue this discussion. >>> >>>Diagrams are always hard because people see them differently. >>> >>> > >>> > If we discuss what "expected" congestion is, that should be under >>> > section 2, which we plan to re-title as Concepts, rather than just >>> > Definitions. >>> >>>Yes, fair enough - expected needs actual explanation >>> >>> > >>> > That's also where I promised David we would discuss the timescale >>> > subtelties of the congestion-volume metric. >>> > >>> > >>> > >I actually think BOTH diagrams are useful. Bob's diagram makes it >>> > clear >>> > >where ConEx fits into the existing congestion feedback architecture, >>> > while >>> > >John's diagram is useful for showing the delay in the signal. I would >>> > >suggest Bob's diagram is better for the introduction, but I would be >>> > keen to >>> > >have John's time-based diagram included somewhere (as it will make >>> > more >>> > >sense to those people who are used to such diagrams). >>> > >>> > People expect a protocol timing diag to have diagonal lines. >>> >>>Agreed, that is a mechanism thing >>> >>> > >>> > Personally I don't think we should try to discuss protocol timing in >>> > concepts-uses. It's virtually impossible to talk about it in a >>> > mechanism-neutral way. >>> >>>I am actually not 100% sure you can avoid all mechanism and protocol= details >>>whilst still having a concepts and use cases document that makes sense. I >>>know we have to ensure that the majority of mechanism is in= abstract-mech, >>>but you may need a bit in order to explain the concept >>> >>> > >>> > We have this in abstract-mech (I can't remember if it's in the >>> > published version or the next rev that has my updates and is sitting >>> > waiting for Matt to add his). >>> > >>> > >>> > > > >>> > > > > I wouldn't say 'ignored' because that could imply everything= else >>> > > > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is= used. >>> > > > >>> > > > I agree "ignored" isn't the right word. Perhaps "not used". >>> > > >>> > >"not used" is better, since there might be a need to have a check >>> > later on >>> > >(as I mentioned above), or at least paranoid end-systems might want= to >>> > be >>> > >able to check it! However that still has an implication that other >>> > things do >>> > >"use" the signal. >>> > >>> > As I said once, saying "not used", "ignored" or anything here is >>> > pre-judging how ConEx is used by the receiver. This was deliberately >>> > left blank. >>> > >>> >>>OK, I have now looked back at your diagram and agree that it is much= clearer >>>without this >>> >>> > >>> > > > >>> > > > > I agree we could remove 'in data packet headers' because it's >>> > > > > mechanism, but on balance I thought it might undertanding help >>> > > > > to leave it in. >>> > > > >>> > > > I don't agree. It's pure mechanism -- while "IP-layer" steers >>> > clear >>> > > > of mechanism. >>> > > >>> > >Agree with John - in data packet headers is mechanism. The key point >>> > here >>> > >(surely) is that the signal must be visible to devices that want to >>> > see it? >>> > >That sort of implies packet header, but only if you assume a packet- >>> > oriented >>> > >IP layer (and I personally think ConEx can apply in other >>> > architectures in >>> > >future) >>> > >>> > Er, can we stay a little grounded here. This is the IETF, not the >>> > "Inter-Galactic Packet Network Standards Force". >>> >>>I know! >>> >>> > >>> > For the IETF, "in the IP layer" means the same as "in IP packet >>> > headers". Because there is only IP payload and IP headers in the IP >>> > layer. And we're not putting ConEx in the payload. >>> >>>So let's say "in the IP layer". As soon as you explicitly state in the >>>packet header you will get shouts of "mechanism" (though this is perhaps= a >>>case in point where you will find it hard to excise all mechanism from= this >>>document) >>> >>> > >>> > In concepts-uses we are only not talking about mechanism in order not >>> > to pre-judge later decisions. There is no alternative on the table >>> > other than signalling ConEx in data packet headers, so we can assume >>> > it. If we abstract for abstraction's sake, no-one will understand. >>> >>>I don't see how not specifying where the conex info is carried is going= to >>>confuse? >>> >>>One key driver for keeping the mechanism out of this draft was that I got >>>told off by the WGCs for having mechanism in an earlier version... >>> >>>Toby >>> >>> > >>> > >>> > Bob >>> > >>> > >>> > >Toby >>> > > >>> > > >>> > > > >>> > > > > have to go... more later... >>> > > > >>> > > > Thanks. >>> > > > >>> > > > -- >>> > > > John Leslie >>> > > > _______________________________________________ >>> > > > conex mailing list >>> > > > conex@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/conex >>> > >>> > ________________________________________________________________ >>> > Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From bob.briscoe@bt.com Sun Jun 26 02:50:01 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A38222800D for ; Sun, 26 Jun 2011 02:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kn15uL0omMq for ; Sun, 26 Jun 2011 02:50:00 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 24BDA228005 for ; Sun, 26 Jun 2011 02:49:59 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 10:49:58 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 10:49:58 +0100 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 1309081797574; Sun, 26 Jun 2011 10:49:57 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.176.11]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5Q9ntip010098; Sun, 26 Jun 2011 10:49:56 +0100 Message-Id: <201106260949.p5Q9ntip010098@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 26 Jun 2011 10:49:55 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: <8WNfnIBH.1309042549.4323470.karagian@ewi.utwente.nl> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <8WNfnIBH.1309042549.4323470.karagian@ewi.utwente.nl> 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: 26 Jun 2011 09:49:58.0277 (UTC) FILETIME=[68ED2B50:01CC33E6] Cc: conex@ietf.org Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 09:50:01 -0000 Georgios, The context of those sentences in RFC6077 (which incidentally I wrote), was to prove that *if* the network wants to do congestion control, claims that it can do this without flow state (e.g. with XCP/RCP) overlook the need for inter-domain policing, which will require flow state. The statement about flow state wasn't intended to be taken out of context as a general statement that identifying flows is always unnecessary. It's only in the context where the network is already trying to control congestion at the flow level. [Anyway, in general (but not in this case) just because a previous IRTF document (RFC6077) says something is impossible, doesn't mean a later IETF doc cannot standardise something that makes it possible.] Bob At 23:55 25/06/2011, Georgios Karagiannis wrote: >Hi Bob, > >Sorry for the delay on sending comments! > >I have a comment regarding the following paragraph: > > > With ConEx there is no need for the network provider to identify > > specific applications or behaviours at the flow level, because the > > relevant bulk congestion information is revealed at the network > > layer. Also, because ConEx information is added explicitly at the IP > > layer, it is visible to provider and consumer alike. Therefore > > traffic contracts or acceptable use policies can be based on a metric > > that is transparent to both parties and is sufficient to manage > > traffic without extra non-transparent wriggle-room and caveats. > >In the paragrah above it is mentioned that the network provider to >identify >specific applications or behaviours at the flow level, because the >relevant bulk congestion information is revealed at the network >layer. > >However, according to RFC 6077, in multi-domain scenarios, due to the >non-cooperative nature of multi-domain environments, it seems unlikely >that network flow state could be avoided (up to a certain extend) given >the network's per-packet flow rate instructions that would need to be >compared against variations in the actual flow rate, which is >inherently not a per-packet metric. > >For RFC 6077, see: >http://www.rfc-editor.org/rfc/rfc6077.txt > >Is it possible to explain in the draft how the congestion control related >issues associated with multi-domain scenarios discussed in RFC 6077 are >solved/worked out? > >Best regards, >Georgios > > > > >On 6/14/2011, "Bob Briscoe" wrote: > > >ConEx folks, > > > >After the last IETF in Prague, we agreed to work on a revised > >draft-ietf-conex-concepts-uses. We're planning on using a lot of the > >text as is, but we suggested that the Introduction needed a complete > >re-write. Below is our joint proposal. > > > >Please bash. > > > >Rationale for this Introduction: > >=============================== > >* The main change is a shift to the main target use-case in the body > >of the document: traffic management, leaving defining congestion etc > >to the definitions and concepts section (section 2). > >* Introduce enough of the solution to allow the reader to grasp > the main logic. > >* Introduce one primary use and mention there are others - to keep > >focused but hint at breadth. > >* Start to weave in some benefits bullet points (transparency, neutrality). > >* Hint at controversies like the over-provisioning issue in the first > >para, but leave addressing this to later, when we can go into the > >subject properly. > > > > > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >1. Introduction > > > > The power of Internet technology comes from multiplexing shared > > capacity with packets rather than circuits. Network operators > > usually provide sufficient capacity, but whenever too much packet > > load meets too little shared capacity, congestion results. > > Congestion appears as either increased delay, missing packets or > > packets explicitly marked with ECN [RFC3168]. The classic Internet > > architecture is arranged so that receivers detect such signs of > > congestion and feed them back end-to-end. Then, ideally, most > > senders reduce their rate in response. > > > > The purpose of this document is to motivate a new congestion exposure > > (ConEx) field at the IP layer. The idea is to add a third pass to > > the feedback loop so that the sender can relay congestion information > > back into the internetwork layer, exposing the level of congestion > > the sender expects packets to experience along their whole path > > (Figure 1). Then certain network nodes can use this new information > > at the IP layer, for example as input to traffic management. > > > > ,---------. ,---------. > > |Transport| |Transport| > > | Sender | |Receiver | > > | |<==Feedback=Path==============================<| | > > | ,---|<--Transport Layer returned Congestion Signal-<|<--. | > > | | | | | | > > | | | | | | > > | | | ,-----------. | | | > > | | | |(Congested)| | | | > > | | |>=Data=Path=>| Network |>=====Data=Path=====>| | | > > | | | | Device |>-Congestion-Signal->|---' | > > | | | `-----------' | | > > | `-->|>---------(new) IP layer ConEx Signal--------->| | > > | | (Carried in Data Packet Headers) | | > > `---------' `---------' > > > > Figure 1: Where the ConEx Protocol Fits in the Internet Architecture > > > > This document serves as the entry point to the set of ConEx > > documentation, giving the 'why' rather than the 'how'. A companion > > document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech]. > > > > The main aim of ConEx is to support evolution of alternatives to the > > proliferation of traffic management solutions that are over- > > constraining, non-transparent and often not application-neutral. > > Traffic management ought to be able to leave end systems free to > > choose how to behave without undue interference, while simultaneously > > satisfying the main concern of network operators; to control traffic > > from some users that excessively limits the freedoms of others. > > > > Freedoms only actually collide when shared capacity becomes > > congested--when a link is full so that a greater share for one user > > would necessarily leave less for someone else. Current traffic > > management solutions typically limit volume or bit-rate in order to > > reduce the likelihood of congestion--limiting one thing in the hope > > it might limit another. However, there is no real need to count > > volume that is sent when there is no congestion, and there is no real > > need to limit bit-rate when there is no congestion. > > > > ConEx markings on packets add the missing information network > > operators need to get a handle on congestion itself. Then they can > > directly limit and control traffic based on how much it contributes > > to congestion and leave traffic unconstrained if it doesn't cause > > congestion. The idea is for the operator to be able to count and > > control the bulk volume or bit-rate of packets marked for congestion > > and disregard packets not contributing to congestion. > > > > With ConEx there is no need for the network provider to identify > > specific applications or behaviours at the flow level, because the > > relevant bulk congestion information is revealed at the network > > layer. Also, because ConEx information is added explicitly at the IP > > layer, it is visible to provider and consumer alike. Therefore > > traffic contracts or acceptable use policies can be based on a metric > > that is transparent to both parties and is sufficient to manage > > traffic without extra non-transparent wriggle-room and caveats. > > > > In summary, ConEx is designed to make it simple to do traffic > > management that is transparent, neutral and not over-constrained. > > Although there is no implication that network operators ought to > > provide such an unconstrained, transparent, neutral service, it > > certainly should not be impossible and ideally it should be the > > simplest service to provide. > > > > The IP layer is intended to engender new applications and behaviours > > and to work over all existing and new lower layer technologies. > > ConEx is a generative technology in this vein, with a range of > > potential uses. This document focuses initially on traffic > > management before widening out to introduce some additional important > > uses for ConEx as well as brifly mentioning a few others. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > > >Bob Briscoe & Rich Woundy > > > > > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Michael.Scharf@alcatel-lucent.com Sun Jun 26 03:28:19 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91721F8509 for ; Sun, 26 Jun 2011 03:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+LOL0w7mtX3 for ; Sun, 26 Jun 2011 03:28:18 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1F01E21F8507 for ; Sun, 26 Jun 2011 03:28:17 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p5QAS1gC003570; Sun, 26 Jun 2011 12:28:01 +0200 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: Sun, 26 Jun 2011 12:28:01 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAC@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <201106260949.p5Q9ntip010098@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] draft-ietf-conex-concepts-uses: New Intro text Thread-Index: Acwz5m8rxHEcZhuySbGlOZsg6tR4WwAAiMlw References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk><8WNfnIBH.1309042549.4323470.karagian@ewi.utwente.nl> <201106260949.p5Q9ntip010098@bagheera.jungle.bt.co.uk> From: "SCHARF, Michael" To: "Bob Briscoe" , "Georgios Karagiannis" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: conex@ietf.org Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 10:28:19 -0000 Georgios, Bob, I've not followed this discussion. But as another author of RFC 6077 I want to back Bob's explanation concerning the context. Those sentences indeed discuss open issues in case that the network performs flow-level congestion control (XCP, RCP, etc.). Michael > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]=20 > On Behalf Of Bob Briscoe > Sent: Sunday, June 26, 2011 11:50 AM > To: Georgios Karagiannis > Cc: conex@ietf.org > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text >=20 > Georgios, >=20 > The context of those sentences in RFC6077 (which incidentally=20 > I wrote), was to prove that *if* the network wants to do=20 > congestion control, claims that it can do this without flow=20 > state (e.g. with > XCP/RCP) overlook the need for inter-domain policing, which=20 > will require flow state. >=20 > The statement about flow state wasn't intended to be taken=20 > out of context as a general statement that identifying flows=20 > is always unnecessary. It's only in the context where the=20 > network is already trying to control congestion at the flow level. >=20 > [Anyway, in general (but not in this case) just because a=20 > previous IRTF document (RFC6077) says something is=20 > impossible, doesn't mean a later IETF doc cannot standardise=20 > something that makes it possible.] >=20 >=20 > Bob >=20 > At 23:55 25/06/2011, Georgios Karagiannis wrote: > >Hi Bob, > > > >Sorry for the delay on sending comments! > > > >I have a comment regarding the following paragraph: > > > > > With ConEx there is no need for the network provider=20 > to identify > > > specific applications or behaviours at the flow level,=20 > because the > > > relevant bulk congestion information is revealed at the network > > > layer. Also, because ConEx information is added=20 > explicitly at the IP > > > layer, it is visible to provider and consumer alike. Therefore > > > traffic contracts or acceptable use policies can be=20 > based on a metric > > > that is transparent to both parties and is sufficient to manage > > > traffic without extra non-transparent wriggle-room and caveats. > > > >In the paragrah above it is mentioned that the network provider to=20 > >identify specific applications or behaviours at the flow=20 > level, because=20 > >the relevant bulk congestion information is revealed at the network=20 > >layer. > > > >However, according to RFC 6077, in multi-domain scenarios,=20 > due to the=20 > >non-cooperative nature of multi-domain environments, it=20 > seems unlikely=20 > >that network flow state could be avoided (up to a certain extend)=20 > >given the network's per-packet flow rate instructions that=20 > would need=20 > >to be compared against variations in the actual flow rate, which is=20 > >inherently not a per-packet metric. > > > >For RFC 6077, see: > >http://www.rfc-editor.org/rfc/rfc6077.txt > > > >Is it possible to explain in the draft how the congestion control=20 > >related issues associated with multi-domain scenarios=20 > discussed in RFC=20 > >6077 are solved/worked out? > > > >Best regards, > >Georgios > > > > > > > > > >On 6/14/2011, "Bob Briscoe" wrote: > > > > >ConEx folks, > > > > > >After the last IETF in Prague, we agreed to work on a revised=20 > > >draft-ietf-conex-concepts-uses. We're planning on using a=20 > lot of the=20 > > >text as is, but we suggested that the Introduction needed=20 > a complete=20 > > >re-write. Below is our joint proposal. > > > > > >Please bash. > > > > > >Rationale for this Introduction: > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > >* The main change is a shift to the main target use-case=20 > in the body=20 > > >of the document: traffic management, leaving defining=20 > congestion etc=20 > > >to the definitions and concepts section (section 2). > > >* Introduce enough of the solution to allow the reader to grasp > > the main logic. > > >* Introduce one primary use and mention there are others - to keep=20 > > >focused but hint at breadth. > > >* Start to weave in some benefits bullet points=20 > (transparency, neutrality). > > >* Hint at controversies like the over-provisioning issue=20 > in the first=20 > > >para, but leave addressing this to later, when we can go into the=20 > > >subject properly. > > > > > > > > > > >=20 > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > >\ > > >1. Introduction > > > > > > The power of Internet technology comes from multiplexing shared > > > capacity with packets rather than circuits. Network operators > > > usually provide sufficient capacity, but whenever too=20 > much packet > > > load meets too little shared capacity, congestion results. > > > Congestion appears as either increased delay, missing=20 > packets or > > > packets explicitly marked with ECN [RFC3168]. The=20 > classic Internet > > > architecture is arranged so that receivers detect such signs of > > > congestion and feed them back end-to-end. Then, ideally, most > > > senders reduce their rate in response. > > > > > > The purpose of this document is to motivate a new=20 > congestion exposure > > > (ConEx) field at the IP layer. The idea is to add a=20 > third pass to > > > the feedback loop so that the sender can relay=20 > congestion information > > > back into the internetwork layer, exposing the level=20 > of congestion > > > the sender expects packets to experience along their whole path > > > (Figure 1). Then certain network nodes can use this=20 > new information > > > at the IP layer, for example as input to traffic management. > > > > > > ,---------. =20 > ,---------. > > > |Transport| =20 > |Transport| > > > | Sender | =20 > |Receiver | > > > | =20 > = |<=3D=3DFeedback=3DPath=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<| | > > > | ,---|<--Transport Layer returned Congestion=20 > Signal-<|<--. | > > > | | | =20 > | | | > > > | | | =20 > | | | > > > | | | ,-----------. =20 > | | | > > > | | | |(Congested)| =20 > | | | > > > | | |>=3DData=3DPath=3D>| Network =20 > |>=3D=3D=3D=3D=3DData=3DPath=3D=3D=3D=3D=3D>| | | > > > | | | | Device =20 > |>-Congestion-Signal->|---' | > > > | | | `-----------' =20 > | | > > > | `-->|>---------(new) IP layer ConEx=20 > Signal--------->| | > > > | | (Carried in Data Packet Headers) =20 > | | > > > `---------' =20 > `---------' > > > > > > Figure 1: Where the ConEx Protocol Fits in the Internet=20 > > > Architecture > > > > > > This document serves as the entry point to the set of ConEx > > > documentation, giving the 'why' rather than the 'how'.=20 > A companion > > > document outlines the ConEx protocol mechanism=20 > [ConEx-Abstract-Mech]. > > > > > > The main aim of ConEx is to support evolution of=20 > alternatives to the > > > proliferation of traffic management solutions that are over- > > > constraining, non-transparent and often not=20 > application-neutral. > > > Traffic management ought to be able to leave end=20 > systems free to > > > choose how to behave without undue interference, while=20 > simultaneously > > > satisfying the main concern of network operators; to=20 > control traffic > > > from some users that excessively limits the freedoms of others. > > > > > > Freedoms only actually collide when shared capacity becomes > > > congested--when a link is full so that a greater share=20 > for one user > > > would necessarily leave less for someone else. Current traffic > > > management solutions typically limit volume or=20 > bit-rate in order to > > > reduce the likelihood of congestion--limiting one=20 > thing in the hope > > > it might limit another. However, there is no real=20 > need to count > > > volume that is sent when there is no congestion, and=20 > there is no real > > > need to limit bit-rate when there is no congestion. > > > > > > ConEx markings on packets add the missing information network > > > operators need to get a handle on congestion itself. =20 > Then they can > > > directly limit and control traffic based on how much=20 > it contributes > > > to congestion and leave traffic unconstrained if it=20 > doesn't cause > > > congestion. The idea is for the operator to be able=20 > to count and > > > control the bulk volume or bit-rate of packets marked=20 > for congestion > > > and disregard packets not contributing to congestion. > > > > > > With ConEx there is no need for the network provider=20 > to identify > > > specific applications or behaviours at the flow level,=20 > because the > > > relevant bulk congestion information is revealed at the network > > > layer. Also, because ConEx information is added=20 > explicitly at the IP > > > layer, it is visible to provider and consumer alike. Therefore > > > traffic contracts or acceptable use policies can be=20 > based on a metric > > > that is transparent to both parties and is sufficient to manage > > > traffic without extra non-transparent wriggle-room and caveats. > > > > > > In summary, ConEx is designed to make it simple to do traffic > > > management that is transparent, neutral and not=20 > over-constrained. > > > Although there is no implication that network=20 > operators ought to > > > provide such an unconstrained, transparent, neutral service, it > > > certainly should not be impossible and ideally it should be the > > > simplest service to provide. > > > > > > The IP layer is intended to engender new applications=20 > and behaviours > > > and to work over all existing and new lower layer technologies. > > > ConEx is a generative technology in this vein, with a range of > > > potential uses. This document focuses initially on traffic > > > management before widening out to introduce some=20 > additional important > > > uses for ConEx as well as brifly mentioning a few others. > >=20 > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > >\ > > > > > > > > >Bob Briscoe & Rich Woundy > > > > > > > > > > > >_______________________________________________ > > >conex mailing list > > >conex@ietf.org > > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From marcelo@it.uc3m.es Sun Jun 26 06:46:11 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A634D21F84DE for ; Sun, 26 Jun 2011 06:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjn0E43p+MaO for ; Sun, 26 Jun 2011 06:46:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 83D9B21F84DD for ; Sun, 26 Jun 2011 06:46:09 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (35.50.22.95.dynamic.jazztel.es [95.22.50.35]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 6BE92750EFD; Sun, 26 Jun 2011 15:46:02 +0200 (CEST) Message-ID: <4E073819.1080304@it.uc3m.es> Date: Sun, 26 Jun 2011 15:46:01 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> In-Reply-To: <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18222.007 Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 13:46:11 -0000 below... El 26/06/11 11:26, Bob Briscoe escribió: > Marcelo, > > Thanks for this. > > There's another option between your options 1 & 2, which I would like > to argue for (and perhaps this is what you were really thinking of): > > Option 1.5: Reference abstract-mech, but summarise (rather than copy) > anything particularly relevant, so that concepts-uses is > self-contained enough to be read first. > > Reasoning: people don't want to read about a mechanism if they don't > know why it might be useful. So we ought to make the 'why' doc the > recommended entry-point. Then if that convinces them, they can read > the 'how' doc for more details. > as co-chair, i think this is perfectly fine is the wg feels that's the way to go. I do believe that it is more importnat to move forward than the actual approach taken to deal with this though As an individual, i still believe that simply referencing the abstract mechanism is fine. People who don't understand the mechanisms are not imho the expected audience of this document. but again, i won't opose any appraoch people will preffer. Regards, marcelo > I don't like pure option 1 (heavily reference abstract-mech). If > information elsewhere is critical to the understanding of a doc, I > believe its poor writing style to use a bare reference to the other > doc without at least a brief summary of the concept the reader needs. > > [Nonetheless, I admit this is going to get unweildy, given > concepts-uses has a section on partial deployment. That's very hard to > talk about without extensive prior knowledge of the mechanism. But > let's at least try it and see.] > > > Bob > > > At 08:35 26/06/2011, marcelo bagnulo braun wrote: >> Hi, >> >> speaking as a WG co-chair >> below... >> >> >> El 23/06/11 17:06, Bob Briscoe escribió: >>> Marcelo, Nandita, >>> >>> Pls give guidance as wg chairs, so we don't write text you will >>> later ask us to remove... >>> >>> We (the editors) are having trouble with the requirement not to >>> describe mechanism in conex-concepts-uses. People on the list seem >>> to agree that some very high level description of ConEx mechanism is >>> necessary in order to make sense of following text. The question is, >>> where to draw the line. >> so, having the use cases separated from the mechanism description is >> an artifact from the wh charter creation process. >> Nevertheless, there are plenty of cases where use cases or >> applicability statements are described in different documents than >> the actual mechanisms, so, that should be feasible. >> The wierd thing is our case is that we are supposed to deliver the >> use case document before the mechanism description. >> >> I agree that in order to understand the use cases the reader needs to >> understand the actual mechanism. >> >> So, i think we have several options here: >> >> 1- Since we have a mature mechanism document, we can simply rely on >> it to describe the mechanism and assume that reader will read the >> abstract mechanism before reading the use case document. We can even >> include a normative reference and even if we ship the use case >> document to the IESG first, both docs will have to be published >> together. >> >> 2- We can copy part of the mechanism defined in the mechanism draft >> into the use case draft, in order to make it more self contained. The >> problem with this is that these two docs needs to be highly >> coordinated, in order to avoid contradictions between the docs. >> >> 3- We can decide to merge the 2 documents. That would require us to >> talk to the iesg and convice them that this is the best approach, but >> if the WG feels this is the way to go, we can try it. >> >> So, I think we can do any of these 3. So far we have been oscilating >> between 1 and 2, which falls within what is specified in the charter, >> which i guess would make our progress easier. >> >> That being said, it is up to the wg to choose whic appraoch is better >> (or to suggest other approaches) >> >> Speaking as an individual now, i believe that is easier and more >> practical to go for option 1. Assume that the reader has read the >> abstract mechanism and heavily reference it and talk about the >> mechanism as described in there. We should ship them both toghter to >> the IESG, even if they don't consider the mechanism one for >> publication until the use case has been through. >> >> Regards, marcelo >> >> >>> Certainly, it is good discipline to be able to describe the problem >>> without describing the mechanism of a solution. But concepts-uses >>> covers more than the problem. It also has to describe central >>> concepts. If we describe central concepts without some degree of >>> mechanism description, it's going to be one of those weird documents >>> that commits to nothing and becomes content-free. For example... >>> >>> >>> The list seems happy that something pirtched at the level of how the >>> ConEx charter describes the mechanism is fine (plus a picture a bit >>> like the first one in abstract-mech). But we seem to need more to >>> support later text. For example: >>> >>> 1/ Timing >>> In the Concepts section (the new name for section 2 on Definitions) >>> we plan to explain what we mean by 'expected congestion' by talking >>> about the sender starting off signalling a conservative expectation >>> of congestion when it has no info about the path, then once it gets >>> e2e transport feedback, it can continually re-insert the feedback >>> into the IP layer as its expectation of congestion. >>> >>> 2/ Headers >>> I prefer to say ConEx info is put in packet headers at the IP layer. >>> Some argue we should just say "at the IP layer" without mentioning >>> headers. I think it's clearer to mention packet headers. >>> >>> My logic is that the rule against speaking about mechanism is >>> primarily designed to avoid prejudging later mechanism documents. >>> However, if abstract-mech is already settled on a decision, and if >>> describing it in concepts-uses is essential background to explain a >>> concept, I would rather just do that, than dance around in >>> abstract-land. >>> >>> Otherwise readers might imagine we could be talking about backward >>> ICMP messages or something, and get confused. >>> >>> >>> >>> Bob >>> >>> At 19:15 17/06/2011, Toby Moncaster wrote: >>> >>> >>>> > -----Original Message----- >>>> > From: Bob Briscoe [mailto:bob.briscoe@bt.com] >>>> > Sent: 17 June 2011 18:38 >>>> > To: Toby Moncaster >>>> > Cc: 'John Leslie'; 'ConEx IETF list' >>>> > Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text >>>> > >>>> > TOby, >>>> > >>>> > Deliberately responding to the middle of the thread, inline... >>>> > >>>> > At 17:43 16/06/2011, Toby Moncaster wrote: >>>> > >>>> > > > -----Original Message----- >>>> > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >>>> > Behalf >>>> > > > Of John Leslie >>>> > > > Sent: 16 June 2011 14:54 >>>> > > > To: Bob Briscoe >>>> > > > Cc: ConEx IETF list >>>> > > > Subject: Re: [conex] draft-ietf-conex-concepts-uses: New >>>> Intro text >>>> > > > >>>> > > > Bob Briscoe wrote: >>>> > > > > At 22:39 15/06/2011, John Leslie wrote: >>>> > > > >> >>>> > > > >> The purpose of this document is to motivate a new congestion >>>> > > > >> exposure (ConEx) field at the IP layer. The idea is to extend >>>> > > > >> the feedback to a complete loop, such that the sender >>>> marks as >>>> > > > >> 'Congestion Expected' the level of congestion reported to >>>> it in >>>> > > > >> the next packet(s) it sends. >>>> > > > > >>>> > > > > This removes the pointers to where we are in the diag (that >>>> > Michael >>>> > > > > asked me to add, and I agreed would help lost readers). >>>> > > > >>>> > > > Hmm... not sure what you mean... In any case, the reader >>>> would >>>> > have >>>> > > > forgotten this text by the time s/he gets to the diagram. >>>> > > >>>> > >Although the diagram could refer back. Personally, when I come >>>> across >>>> > text >>>> > >like this and there is a diagram, I feel the text should point >>>> to the >>>> > >diagram, but should be clear enough to work for people that don't >>>> > think in >>>> > >pictures... >>>> > > >>>> > > > >>>> > > > > I don't think 'complete loop' is useful as people already >>>> think >>>> > of it >>>> > > > > as a complete loop before ConEx. This also might make newbies >>>> > think >>>> > > > > that the router that generates the congestion signal also >>>> always >>>> > > > > reads the ConEx signal. >>>> > > > >>>> > > > I agree "loop" isn't the right word. >>>> > > >>>> > >Especially it isn't right as ConEx should work in transports where >>>> > there is >>>> > >no congestion feedback. >>>> > > >>>> > >We do need to make it clear that no router needs to read the ConEx >>>> > signal >>>> > >(though any router should be able to if it so wishes) >>>> > >>>> > We don't even need to say the parenthesis. >>>> >>>> Indeed. I just wanted to make it clear to people reading this >>>> thread -- >>>> there are still people that believe ConEx requires every device to >>>> understand it >>>> >>>> > >>>> > >>>> > > > >>>> > > > > "...to add a third pass to the feedback loop" says exactly >>>> what >>>> > is >>>> > > > > happening, doesn't it? >>>> > > > >>>> > > > Perhaps in your mind... I don't think it conveys that to the >>>> > reader, >>>> > > > though. >>>> > > >>>> > >Surely at that point ConEx is feed-forward, not feedback? >>>> Otherwise it >>>> > might >>>> > >sound like you expect the receiver to acknowledge how much ConEx >>>> > signal it >>>> > >saw (which you might want as some sort of nonce for data >>>> validity, but >>>> > isn't >>>> > >part of the core ConEx signal). >>>> > > >>>> > >I will try and think of a clearer way to express this. I know this >>>> > won't >>>> > >just slot straight into the text, but how about: >>>> > > >>>> > >"Congestion control currently relies on the receiver informing the >>>> > sender of >>>> > >any congestion it has seen. The sender then responds to such >>>> > congestion >>>> > >indications in order to reduce the congestion. ConEx requires the >>>> > sender to >>>> > >state how much congestion it expects to cause by sending a >>>> "congestion >>>> > >experienced" signal with any data it sends. This ConEx signal >>>> travels >>>> > >unchanged through the network to the receiver and can be seen at >>>> any >>>> > >intermediate routers or devices that choose to read it." >>>> > >>>> > That's pretty good. But again, I would deconfuse by simply saying: >>>> > s/intermediate routers or devices/IP layer devices/ >>>> >>>> That is clearer and covers all sensible possibilities. >>>> >>>> > >>>> > >>>> > > > >>>> > > > We might try something more in line with "in both >>>> directions". >>>> > > > I think the point is that the added congestion signal needs to >>>> > travel >>>> > > > in the same direction the data experiencing congestion traveled, >>>> > and >>>> > > > needs to follow the whole path. >>>> > > >>>> > >And the SAME path! i.e. it shouldn't be taking the slow path in >>>> > routers. >>>> > >>>> > Fast/slow path is mechanism. >>>> >>>> OK, fair point. >>>> >>>> > >>>> > Same path isn't absolutely necessary, as long as it's typical. Like >>>> > packets of a flow, they can change path, but you don't want them to >>>> > have to be pinned ONLY to one path. So I wouldn't bring path up here >>>> > (this is introduction). >>>> >>>> OK you're right that we don't want too much detail in an >>>> introduction. There >>>> might be a need to discuss these sort of details in another document >>>> (perhaps as an appendix?) >>>> >>>> > >>>> > >>>> > >>>> > > > >>>> > > > >> +---------+ +-----------+ >>>> +--- >>>> > ---- >>>> > > > --+ >>>> > > > >> |Transport| | Congested | >>>> > > > |Transport| >>>> > > > >> | Sender | | Network | | >>>> > > > Receiver| >>>> > > > >> | |=Data=Path==>| Device |======Data=Path=====>| >>>> > > > | >>>> > > > >> | | | >>>> |-Congestion-Signal-->|-- >>>> > >+ >>>> > > > | >>>> > > > >> | | . . | >>>> > | >>>> > > > | >>>> > > > >> | +<--|<--Transport-.---Layer---.<--Congestion >>>> Signal-|<-- >>>> > + >>>> > > > | >>>> > > > >> | | | . . | >>>> > > > | >>>> > > > >> | | | | | | >>>> > > > | >>>> > > > >> | | |=Data=Path==>| |======Data=Path=====>| >>>> > > > | >>>> > > > >> | +-->|-->(new)--IP-.---Layer---.-Congestion >>>> Signal-->|-- >>>> > >+ >>>> > > > | >>>> > > > >> | | . . | >>>> > | >>>> > > > | >>>> > > > >> | | . . >>>> > > > |(ignored)| >>>> > > > >> | | | | | >>>> > > > | >>>> > > > >> +---------+ +-----------+ >>>> +--- >>>> > ---- >>>> > > > --+ >>>> > > > >> >>>> > > > >> Figure 1: Where the ConEx Protocol Fits in the Internet >>>> > > > Architecture >>>> > > > > >>>> > > > > We obviously have two different implicit y axes. You're >>>> thinking >>>> > of >>>> > > > > time down the page, I'm thinking of layering. I think this >>>> shows >>>> > we >>>> > > > > need to label both (layers and time). >>>> > > > >>>> > > > Good catch! My Transport Layer Congestion Signal needs >>>> "=", not >>>> > "-". >>>> > > > " >>>> > > > " | >>>> +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+ >>>> > > > | >>>> > > > >>>> > > > The reader expects time to be the downward Y-axis. Making it >>>> > > > anything >>>> > > > else will tend to confuse the reader. >>>> > >>>> > I think John means "confuse readers who think like John" >>>> > My suggestion was to label the axis, so people don't have to guess. >>>> > Then we don't have to continue this discussion. >>>> >>>> Diagrams are always hard because people see them differently. >>>> >>>> > >>>> > If we discuss what "expected" congestion is, that should be under >>>> > section 2, which we plan to re-title as Concepts, rather than just >>>> > Definitions. >>>> >>>> Yes, fair enough - expected needs actual explanation >>>> >>>> > >>>> > That's also where I promised David we would discuss the timescale >>>> > subtelties of the congestion-volume metric. >>>> > >>>> > >>>> > >I actually think BOTH diagrams are useful. Bob's diagram makes it >>>> > clear >>>> > >where ConEx fits into the existing congestion feedback >>>> architecture, >>>> > while >>>> > >John's diagram is useful for showing the delay in the signal. I >>>> would >>>> > >suggest Bob's diagram is better for the introduction, but I >>>> would be >>>> > keen to >>>> > >have John's time-based diagram included somewhere (as it will make >>>> > more >>>> > >sense to those people who are used to such diagrams). >>>> > >>>> > People expect a protocol timing diag to have diagonal lines. >>>> >>>> Agreed, that is a mechanism thing >>>> >>>> > >>>> > Personally I don't think we should try to discuss protocol timing in >>>> > concepts-uses. It's virtually impossible to talk about it in a >>>> > mechanism-neutral way. >>>> >>>> I am actually not 100% sure you can avoid all mechanism and >>>> protocol details >>>> whilst still having a concepts and use cases document that makes >>>> sense. I >>>> know we have to ensure that the majority of mechanism is in >>>> abstract-mech, >>>> but you may need a bit in order to explain the concept >>>> >>>> > >>>> > We have this in abstract-mech (I can't remember if it's in the >>>> > published version or the next rev that has my updates and is sitting >>>> > waiting for Matt to add his). >>>> > >>>> > >>>> > > > >>>> > > > > I wouldn't say 'ignored' because that could imply >>>> everything else >>>> > > > > doesn't ignore ConEx. Also, that's pre-judging how ConEx is >>>> used. >>>> > > > >>>> > > > I agree "ignored" isn't the right word. Perhaps "not used". >>>> > > >>>> > >"not used" is better, since there might be a need to have a check >>>> > later on >>>> > >(as I mentioned above), or at least paranoid end-systems might >>>> want to >>>> > be >>>> > >able to check it! However that still has an implication that other >>>> > things do >>>> > >"use" the signal. >>>> > >>>> > As I said once, saying "not used", "ignored" or anything here is >>>> > pre-judging how ConEx is used by the receiver. This was deliberately >>>> > left blank. >>>> > >>>> >>>> OK, I have now looked back at your diagram and agree that it is >>>> much clearer >>>> without this >>>> >>>> > >>>> > > > >>>> > > > > I agree we could remove 'in data packet headers' because it's >>>> > > > > mechanism, but on balance I thought it might undertanding help >>>> > > > > to leave it in. >>>> > > > >>>> > > > I don't agree. It's pure mechanism -- while "IP-layer" steers >>>> > clear >>>> > > > of mechanism. >>>> > > >>>> > >Agree with John - in data packet headers is mechanism. The key >>>> point >>>> > here >>>> > >(surely) is that the signal must be visible to devices that want to >>>> > see it? >>>> > >That sort of implies packet header, but only if you assume a >>>> packet- >>>> > oriented >>>> > >IP layer (and I personally think ConEx can apply in other >>>> > architectures in >>>> > >future) >>>> > >>>> > Er, can we stay a little grounded here. This is the IETF, not the >>>> > "Inter-Galactic Packet Network Standards Force". >>>> >>>> I know! >>>> >>>> > >>>> > For the IETF, "in the IP layer" means the same as "in IP packet >>>> > headers". Because there is only IP payload and IP headers in the IP >>>> > layer. And we're not putting ConEx in the payload. >>>> >>>> So let's say "in the IP layer". As soon as you explicitly state in the >>>> packet header you will get shouts of "mechanism" (though this is >>>> perhaps a >>>> case in point where you will find it hard to excise all mechanism >>>> from this >>>> document) >>>> >>>> > >>>> > In concepts-uses we are only not talking about mechanism in order >>>> not >>>> > to pre-judge later decisions. There is no alternative on the table >>>> > other than signalling ConEx in data packet headers, so we can assume >>>> > it. If we abstract for abstraction's sake, no-one will understand. >>>> >>>> I don't see how not specifying where the conex info is carried is >>>> going to >>>> confuse? >>>> >>>> One key driver for keeping the mechanism out of this draft was that >>>> I got >>>> told off by the WGCs for having mechanism in an earlier version... >>>> >>>> Toby >>>> >>>> > >>>> > >>>> > Bob >>>> > >>>> > >>>> > >Toby >>>> > > >>>> > > >>>> > > > >>>> > > > > have to go... more later... >>>> > > > >>>> > > > Thanks. >>>> > > > >>>> > > > -- >>>> > > > John Leslie >>>> > > > _______________________________________________ >>>> > > > conex mailing list >>>> > > > conex@ietf.org >>>> > > > https://www.ietf.org/mailman/listinfo/conex >>>> > >>>> > ________________________________________________________________ >>>> > Bob Briscoe, BT Innovate & Design >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From bob.briscoe@bt.com Sun Jun 26 13:04:21 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2464021F8438 for ; Sun, 26 Jun 2011 13:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfZi712rPeBc for ; Sun, 26 Jun 2011 13:04:20 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id AA07321F8434 for ; Sun, 26 Jun 2011 13:04:16 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 21:04:15 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Jun 2011 21:04:14 +0100 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 1309118654227; Sun, 26 Jun 2011 21:04:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.208.103]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5QK4Bfu011371; Sun, 26 Jun 2011 21:04:12 +0100 Message-Id: <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 26 Jun 2011 21:04:11 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4E073819.1080304@it.uc3m.es> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 26 Jun 2011 20:04:14.0980 (UTC) FILETIME=[393BBC40:01CC343C] Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 20:04:21 -0000 Marcelo, At 14:46 26/06/2011, marcelo bagnulo braun wrote: >El 26/06/11 11:26, Bob Briscoe escribi=F3: >>Marcelo, >> >>Option 1.5: Reference abstract-mech, but=20 >>summarise (rather than copy) anything=20 >>particularly relevant, so that concepts-uses is=20 >>self-contained enough to be read first. >As an individual, i still believe that simply=20 >referencing the abstract mechanism is fine.=20 >People who don't understand the mechanisms are=20 >not imho the expected audience of this document.=20 >but again, i won't opose any appraoch people will preffer. Thanks, that's useful to know. There does seem to be a mismatch of expectations=20 about the audience of concepts-uses here that=20 ought to be cleared up. I thought it was intended=20 to be the entry-point to ConEx; therefore targeted at newbies. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From wes@mti-systems.com Sun Jun 26 19:41:20 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70B11E8098 for ; Sun, 26 Jun 2011 19:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IWbfjHSxTKD for ; Sun, 26 Jun 2011 19:41:20 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1412F11E808B for ; Sun, 26 Jun 2011 19:41:16 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5R2fG6c005634 for ; Sun, 26 Jun 2011 22:41:16 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.93.41] ([174.130.93.41:34266] helo=[192.168.1.100]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 46/E7-17982-CCDE70E4; Sun, 26 Jun 2011 22:41:16 -0400 Message-ID: <4E07EDCB.1030904@mti-systems.com> Date: Sun, 26 Jun 2011 22:41:15 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: conex@ietf.org References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> In-Reply-To: <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 02:41:20 -0000 On 6/26/2011 4:04 PM, Bob Briscoe wrote: > Marcelo, > > At 14:46 26/06/2011, marcelo bagnulo braun wrote: >> El 26/06/11 11:26, Bob Briscoe escribió: >>> Marcelo, >>> >>> Option 1.5: Reference abstract-mech, but summarise (rather than copy) >>> anything particularly relevant, so that concepts-uses is >>> self-contained enough to be read first. >> As an individual, i still believe that simply referencing the abstract >> mechanism is fine. People who don't understand the mechanisms are not >> imho the expected audience of this document. but again, i won't opose >> any appraoch people will preffer. > > Thanks, that's useful to know. > > There does seem to be a mismatch of expectations about the audience of > concepts-uses here that ought to be cleared up. I thought it was > intended to be the entry-point to ConEx; therefore targeted at newbies. > I prefer option 1 or 1.5. I've been thinking of the concepts-uses document primarily like a ConOps for how conex is envisioned to be applied, and then the abstract-mech draft as a sort of architecture description for how the full system can work, with the individual pieces fleshed out in by the packet structure and TCP documents. -- Wes Eddy MTI Systems From marcelo@it.uc3m.es Sun Jun 26 23:05:56 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5A21F8637 for ; Sun, 26 Jun 2011 23:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyrjpvNFoTEv for ; Sun, 26 Jun 2011 23:05:55 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84221F8635 for ; Sun, 26 Jun 2011 23:05:55 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (35.50.22.95.dynamic.jazztel.es [95.22.50.35]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id F1D88B496D9; Mon, 27 Jun 2011 08:05:52 +0200 (CEST) Message-ID: <4E081DC0.3070007@it.uc3m.es> Date: Mon, 27 Jun 2011 08:05:52 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> In-Reply-To: <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18224.003 Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 06:05:56 -0000 El 26/06/11 22:04, Bob Briscoe escribió: > > > There does seem to be a mismatch of expectations about the audience of > concepts-uses here that ought to be cleared up. I thought it was > intended to be the entry-point to ConEx; therefore targeted at newbies. > > mmm, i think scoping the document only to newbies would severely limit what you can do. I see it as the description of what you can achieve with conex, assuming you understand the conex mechanism. I mean, especially in our case that we have an _abstract_ mechanism description, i would argue that the reader of the use case should have read the abstract mechanism first (but may not have read the actual extensions for IPv6 coding or the TCP extensions to support conex) makes sense? Regards, marcelo > Bob > > > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From bob.briscoe@bt.com Mon Jun 27 03:14:58 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47321F85F9 for ; Mon, 27 Jun 2011 03:14:58 -0700 (PDT) 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=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYfYhgwZRtjS for ; Mon, 27 Jun 2011 03:14:57 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7737C21F85F5 for ; Mon, 27 Jun 2011 03:14:56 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 11:14:55 +0100 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, 27 Jun 2011 11:14:54 +0100 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 1309169694534; Mon, 27 Jun 2011 11:14:54 +0100 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 p5RAEpuL013877; Mon, 27 Jun 2011 11:14:51 +0100 Message-Id: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jun 2011 11:14:53 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4E081DC0.3070007@it.uc3m.es> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> <4E081DC0.3070007@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jun 2011 10:14:54.0868 (UTC) FILETIME=[0F609540:01CC34B3] Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 10:14:58 -0000 Marcelo, At 07:05 27/06/2011, marcelo bagnulo braun wrote: >El 26/06/11 22:04, Bob Briscoe escribi=F3: >> >> >>There does seem to be a mismatch of=20 >>expectations about the audience of=20 >>concepts-uses here that ought to be cleared up.=20 >>I thought it was intended to be the entry-point=20 >>to ConEx; therefore targeted at newbies. >> >mmm, i think scoping the document only to=20 >newbies would severely limit what you can do. I=20 >see it as the description of what you can=20 >achieve with conex, assuming you understand the=20 >conex mechanism. I mean, especially in our case=20 >that we have an _abstract_ mechanism=20 >description, i would argue that the reader of=20 >the use case should have read the abstract=20 >mechanism first (but may not have read the=20 >actual extensions for IPv6 coding or the TCP extensions to support conex) > >makes sense? Well, no. Why would anyone read the abstract-mech=20 doc without knowing why they wanted to read it? This conversation is getting a bit disconnected=20 from the real docs. So far, we are quite happily=20 and very briefly summarising the necessary=20 mechanism ideas from abstract-mech into=20 concepts-uses. It sounds like you would be happy=20 to have references to the mechanism and/or brief=20 re-statements of mechanism in concepts-uses. And=20 Nandita was already happy with that. So there's no longer a problem. The question merely arose because Toby was saying=20 he had attempted to have some specifics on=20 mechanism in concepts-uses before, and he'd been=20 asked to make concepts-uses mechanism-independent by the chairs. Bob >Regards, marcelo > > >>Bob >> >> >> >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From marcelo@it.uc3m.es Mon Jun 27 07:01:33 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FDD11E80E4 for ; Mon, 27 Jun 2011 07:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ew6Lpf8--l8 for ; Mon, 27 Jun 2011 07:01:32 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 76DDD11E80E2 for ; Mon, 27 Jun 2011 07:01:29 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (35.50.22.95.dynamic.jazztel.es [95.22.50.35]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 179839B55FD; Mon, 27 Jun 2011 16:01:27 +0200 (CEST) Message-ID: <4E088D36.5040806@it.uc3m.es> Date: Mon, 27 Jun 2011 16:01:26 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> <4E081DC0.3070007@it.uc3m.es> <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> In-Reply-To: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18224.007 Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:01:33 -0000 El 27/06/11 12:14, Bob Briscoe escribió: > > > This conversation is getting a bit disconnected from the real docs. So > far, we are quite happily and very briefly summarising the necessary > mechanism ideas from abstract-mech into concepts-uses. It sounds like > you would be happy to have references to the mechanism and/or brief > re-statements of mechanism in concepts-uses. And Nandita was already > happy with that. So there's no longer a problem. > great, i am glad we are making progress > The question merely arose because Toby was saying he had attempted to > have some specifics on mechanism in concepts-uses before, and he'd > been asked to make concepts-uses mechanism-independent by the chairs. > Let me correct this. The WG input was that this should be removed. Please check the minutes from IETF78 proceedings on the use case document and the feedback received. The WG chairs we were not stating a position on the technical issue, but merely ensuring that the feedback received by the WG was reflected in the document. Regards, marcelo > > Bob > > >> Regards, marcelo >> >> >>> Bob >>> >>> >>> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From rs@netapp.com Mon Jun 27 07:54:47 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BFB21F85EE for ; Mon, 27 Jun 2011 07:54:47 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynr-MQWMgAyo for ; Mon, 27 Jun 2011 07:54:47 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6237C21F85DE for ; Mon, 27 Jun 2011 07:54:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,432,1304319600"; d="scan'208";a="253060388" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 27 Jun 2011 07:54:39 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p5REscEM000618 for ; Mon, 27 Jun 2011 07:54:39 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jun 2011 16:54:38 +0200 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: Mon, 27 Jun 2011 15:54:36 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: conex marks and tcp Thread-Index: Acw0syCDlui4DkIzTSWRLbfGsMOUbQAJZNAQ References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk><4DF792CB.5090207@informatik.uni-tuebingen.de><201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk><4DF7C02C.2020505@informatik.uni-tuebingen.de><201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk><4DF84A1E.5050907@informatik.uni-tuebingen.de><20110615213941.GM96377@verdi><201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk><20110616135429.GN96377@verdi><002d01cc2c44$7ab9d8a0$702d89e0$@com><201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk><000d01cc2d1a$86ed9ae0$94c8d0a0$@com><201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk><4E06E142.5090300@it.uc3m.es><201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk><4E073819.1080304@it.uc3m.es><201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk><4E081DC0.3070007@it.uc3m.es> <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> From: "Scheffenegger, Richard" To: "ConEx IETF list" X-OriginalArrivalTime: 27 Jun 2011 14:54:38.0801 (UTC) FILETIME=[23618410:01CC34DA] Subject: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:54:47 -0000 Sorry to bother the group with this question... I may have missed the discussion around this, but I was wondering the opinion around conex marks for TCP flows. The reason I'm asking is that Conex and ECN are very much tied together for TCP flows. However, ECN is currently not to be used for non-data segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] and [RST]).=20 However, for a bidirectional session, wouldn't it be beneficial to also collect ECN marks (to be fed into Conex) with other types of segment apart from data segments? That would - at least for TCP - appear to be simpler than trying to come up with a new heuristic to detect lost ACKs and use that as source of Conex marks. In addition, ECN-marked segments are supposed to get dropped with lower probability too, making features like AckCC more appealing... Of course, there may be other transports which currently don't allow ECN for certain types of packets; Should the rationale for not having ECN on a global basis be reviewed for Conex enabled stacks? Thanks, Richard Scheffenegger From john@jlc.net Mon Jun 27 08:14:59 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920A911E811B for ; Mon, 27 Jun 2011 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcKM9fqmHZ4x for ; Mon, 27 Jun 2011 08:14:59 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7646A11E80DC for ; Mon, 27 Jun 2011 08:14:58 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A6F6133C24; Mon, 27 Jun 2011 11:14:40 -0400 (EDT) Date: Mon, 27 Jun 2011 11:14:40 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20110627151440.GG56541@verdi> References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:14:59 -0000 Scheffenegger, Richard wrote: > > Sorry to bother the group with this question... Turns out, it's an interesting question... > The reason I'm asking is that Conex and ECN are very much tied together > for TCP flows. However, ECN is currently not to be used for non-data > segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] and > [RST]). Certainly, ECN _could_ be used on these; but there's no obvious reason to -- there's no obvious back-off to be done if congestion is experienced. > However, for a bidirectional session, wouldn't it be beneficial to also > collect ECN marks (to be fed into Conex) with other types of segment > apart from data segments? I see no reason that ConEx credit markings couldn't go in a SYN: indicating an intent to build an initial credit. It does raise some questions about implementation (which seem premature). Thinking it through, this could play a role in DDoS mitigation -- which we've ruled out of the initial presentation. Thus it doesn't seem appropriate for -concepts-uses; but perhaps we might think of hooks when we discuss abstract-mechanism. These non-data packets are effectively part of the flow; and the ConEx mechanism is a Layer-3 beast which doesn't care how the sender learns of congestion experienced. > That would - at least for TCP - appear to be simpler than trying to come > up with a new heuristic to detect lost ACKs and use that as source of > Conex marks. I'm afraid we're stuck considering lost ACKs anyway, though ECN marks are a better mechanism... > In addition, ECN-marked segments are supposed to get dropped with lower > probability too, making features like AckCC more appealing... I'm not sure there's enough consensus yet on lower-drop-probability for ECN-marked packets. :^( > Of course, there may be other transports which currently don't allow ECN > for certain types of packets; Should the rationale for not having ECN on > a global basis be reviewed for Conex enabled stacks? I'm not sure I understand this question. -- John Leslie From bob.briscoe@bt.com Mon Jun 27 08:16:39 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB1711E80F1 for ; Mon, 27 Jun 2011 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VusPhDNuxluc for ; Mon, 27 Jun 2011 08:16:39 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id A99FD11E80FF for ; Mon, 27 Jun 2011 08:16:38 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Jun 2011 16:16:15 +0100 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, 27 Jun 2011 16:16:15 +0100 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 1309187774301; Mon, 27 Jun 2011 16:16:14 +0100 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 p5RFGBC2015052; Mon, 27 Jun 2011 16:16:11 +0100 Message-Id: <201106271516.p5RFGBC2015052@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jun 2011 16:16:14 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4E088D36.5040806@it.uc3m.es> References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> <4E081DC0.3070007@it.uc3m.es> <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <4E088D36.5040806@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Jun 2011 15:16:15.0099 (UTC) FILETIME=[2808E4B0:01CC34DD] Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:16:40 -0000 Marcelo, Thanks - I've gone and read the IETF78 ConEx=20 minutes and been reminded of the pressure at that time. In hindsight I would have pushed back more at the=20 time. It is true that the use-cases part of=20 concepts-uses should be mechanism independent,=20 but it would be overly theoretical to describe=20 the concepts (e.g. downstream congestion-volume)=20 without using mechanisms as examples. We need to constantly remind ourselves that concepts-uses has three= purposes: - describe the problem(s) - concepts - benefits - deployment arrangements (that's four ;) We haven't even got on to the problems with=20 discussing deployment arrangements yet. That will=20 be impossible without introducing mechanism, but=20 I still think there's a separate role for=20 abstract-mech, which has all the precise=20 statements about mechanism, while concepts-uses=20 can treat all the parts as high-level building blocks. Bob At 15:01 27/06/2011, marcelo bagnulo braun wrote: >El 27/06/11 12:14, Bob Briscoe escribi=F3: >>The question merely arose because Toby was=20 >>saying he had attempted to have some specifics=20 >>on mechanism in concepts-uses before, and he'd=20 >>been asked to make concepts-uses mechanism-independent by the chairs. >Let me correct this. The WG input was that this=20 >should be removed. Please check the minutes from=20 >IETF78 proceedings on the use case document and=20 >the feedback received. The WG chairs we were not=20 >stating a position on the technical issue, but=20 >merely ensuring that the feedback received by=20 >the WG was reflected in the document. > >Regards, marcelo > > >> >>Bob >> >> >>>Regards, marcelo >>> >>> >>>>Bob >>>> >>>> >>>> >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From rs@netapp.com Mon Jun 27 08:32:39 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5523511E80CF for ; Mon, 27 Jun 2011 08:32:39 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF9LNhNlii1Z for ; Mon, 27 Jun 2011 08:32:38 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57111E80D3 for ; Mon, 27 Jun 2011 08:32:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,432,1304319600"; d="scan'208";a="261653644" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 27 Jun 2011 08:32:37 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (ldcrsexc2-prd.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p5RFWans006655; Mon, 27 Jun 2011 08:32:36 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jun 2011 16:32:36 +0100 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: Mon, 27 Jun 2011 16:32:34 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110627151440.GG56541@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] conex marks and tcp Thread-Index: Acw03Q5YaCCwfXhrRRm3NYCNXMVEAwAAEsNg References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> <20110627151440.GG56541@verdi> From: "Scheffenegger, Richard" To: "John Leslie" X-OriginalArrivalTime: 27 Jun 2011 15:32:36.0518 (UTC) FILETIME=[71018C60:01CC34DF] Cc: ConEx IETF list Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:32:39 -0000 Hi John, yes, this question is jumping the current discussions on the conex list, and really belongs in the valley of implementation details :) My understanding was, that lost *data* segments will provide the input signal for conex, short of ECN. That is a relatively easy metric to come by within TCP, whereas lost (+delayed) pure ACKs aren't really accounted in TCP stacks. Besides, the congestion information conveyed by lost pure ACKs (no data) is at the wrong end of the connection, and TCP will not convey that information back to the sender of the ACKs (the receiver of the data stream at this point in time), unless the TCP ECN mechanism is used. TCP ECN works bidirectional, so for TCP at least, it appears that Conex would give a high incentive to have all TCP segments ECN-capable.... Using RFC3168 ECN marking with TCP however, seems to make things unnecessary complicated. Whenever the data direction of a TCP flow changes, the Conex machinery may need to be restarted (because information learned before may be long outdated). With always ECN segments, Conex would maintain a good understanding of the network congestion state, and not need to start from scratch... =20 My last remark was with respect to DCCP, SCTP, RTTP and other transport protocols that I'm not really familiar with; they may have similar limitations on their use of ECN-capable packets as TCP, thus similar implications. Just to not leave them out completely - but I guess the Conex/ECN interaction can be discussed with TCP as an example, and carried to these protocol once the WG comes to a consensus.=20 Richard Scheffenegger > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Montag, 27. Juni 2011 17:15 > To: Scheffenegger, Richard > Cc: ConEx IETF list > Subject: Re: [conex] conex marks and tcp >=20 > Scheffenegger, Richard wrote: > > > > Sorry to bother the group with this question... >=20 > Turns out, it's an interesting question... >=20 > > The reason I'm asking is that Conex and ECN are very much tied > together > > for TCP flows. However, ECN is currently not to be used for non-data > > segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] and > > [RST]). >=20 > Certainly, ECN _could_ be used on these; but there's no obvious > reason > to -- there's no obvious back-off to be done if congestion is > experienced. >=20 > > However, for a bidirectional session, wouldn't it be beneficial to > also > > collect ECN marks (to be fed into Conex) with other types of segment > > apart from data segments? >=20 > I see no reason that ConEx credit markings couldn't go in a SYN: > indicating an intent to build an initial credit. It does raise some > questions about implementation (which seem premature). >=20 > Thinking it through, this could play a role in DDoS mitigation -- > which we've ruled out of the initial presentation. >=20 > Thus it doesn't seem appropriate for -concepts-uses; but perhaps we > might think of hooks when we discuss abstract-mechanism. These non-data > packets are effectively part of the flow; and the ConEx mechanism is a > Layer-3 beast which doesn't care how the sender learns of congestion > experienced. >=20 > > That would - at least for TCP - appear to be simpler than trying to > come > > up with a new heuristic to detect lost ACKs and use that as source of > > Conex marks. >=20 > I'm afraid we're stuck considering lost ACKs anyway, though ECN > marks > are a better mechanism... >=20 > > In addition, ECN-marked segments are supposed to get dropped with > lower > > probability too, making features like AckCC more appealing... >=20 > I'm not sure there's enough consensus yet on lower-drop-probability > for ECN-marked packets. :^( >=20 > > Of course, there may be other transports which currently don't allow > ECN > > for certain types of packets; Should the rationale for not having ECN > on > > a global basis be reviewed for Conex enabled stacks? >=20 > I'm not sure I understand this question. >=20 > -- > John Leslie From toby@moncaster.com Mon Jun 27 09:06:03 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6021F85E4 for ; Mon, 27 Jun 2011 09:06:03 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy-ZMLBLhXOi for ; Mon, 27 Jun 2011 09:06:03 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4A21F85E1 for ; Mon, 27 Jun 2011 09:06:02 -0700 (PDT) Received: from TobysHP (host81-156-178-213.range81-156.btcentralplus.com [81.156.178.213]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LeFM9-1RMe1n1zO1-00q9tY; Mon, 27 Jun 2011 18:05:39 +0200 From: "Toby Moncaster" To: "'Scheffenegger, Richard'" , "'John Leslie'" References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> <20110627151440.GG56541@verdi> <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> Date: Mon, 27 Jun 2011 17:05:38 +0100 Message-ID: <002501cc34e4$0ef07810$2cd16830$@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: Acw03Q5YaCCwfXhrRRm3NYCNXMVEAwAAEsNgAAFDkCA= Content-Language: en-gb X-Provags-ID: V02:K0:yUfetptIRTqoBNcZtJO1ynRkNOYMSciWjCJAVisxQFa j63XTmUURNt4qG4RvHEwOvnSAhur1GsR+K7HBbUey1VAVxtkEb obMGkVagNcCtQ0/kV3mXe9VEwmEK/xPdCM2R/jI868wZuFu0OK I+8U8EGjpKQFHM5RpBu7dzrF24SCl2VRPQyH3My85td/BhRnOl kNUtK0wcY1Su0KcnLpMUuswG0ZHhMoGunPOZhYu0J0= Cc: 'ConEx IETF list' Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:06:04 -0000 Speaking personally, I think ConEx certainly should apply to initial packets in any flow (data or not). As I understand it, the main reason RFC3168 ECN didn't apply to SYN, SYN-ACK and ACK was because the transports would also be doing hand-shaking for ECN negotiation. Since then there has been work on activating ECN for SYN-ACK and ACK packets (http://tools.ietf.org/html/rfc5562), but that is only experimental. I seem to recall the authors felt there was a good reason not to implement it on the SYN packet, but I can't for the life of me recall what it was! Inline... > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Scheffenegger, Richard > Sent: 27 June 2011 16:33 > To: John Leslie > Cc: ConEx IETF list > Subject: Re: [conex] conex marks and tcp > > Hi John, > > yes, this question is jumping the current discussions on the conex > list, > and really belongs in the valley of implementation details :) > > My understanding was, that lost *data* segments will provide the input > signal for conex, short of ECN. That is a relatively easy metric to > come > by within TCP, whereas lost (+delayed) pure ACKs aren't really > accounted > in TCP stacks. Besides, the congestion information conveyed by lost > pure > ACKs (no data) is at the wrong end of the connection, and TCP will not > convey that information back to the sender of the ACKs OK that is certainly getting into finer details of implementation and mechanism! One argument goes that every sender (and that includes senders that are just ACKing received data) should respond to every byte of congestion they see. But as you say, ACKs aren't ACKed (otherwise you'd get into an endless cycle) > (the receiver of > the data stream at this point in time), unless the TCP ECN mechanism is > used. TCP ECN works bidirectional, so for TCP at least, it appears that > Conex would give a high incentive to have all TCP segments > ECN-capable.... Yep - ConEx certainly should give a strong incentive to enable ECN for both the end-systems AND the networks - there is already evidence that it would benefit end-systems, but up till now it has only had marginal benefits for the network, hence lack of wide deployment (network operators are not renowned for their altruism) > > Using RFC3168 ECN marking with TCP however, seems to make things > unnecessary complicated. Whenever the data direction of a TCP flow > changes, the Conex machinery may need to be restarted (because > information learned before may be long outdated). With always ECN > segments, Conex would maintain a good understanding of the network > congestion state, and not need to start from scratch... Have you read the earlier documents about re-ECN with TCP? (http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09) Although re-ECN uses the IP part of the ECN mechanism it completely replaced the TCP part > > > > My last remark was with respect to DCCP, SCTP, RTTP and other transport > protocols that I'm not really familiar with; they may have similar > limitations on their use of ECN-capable packets as TCP, thus similar > implications. Just to not leave them out completely - but I guess the > Conex/ECN interaction can be discussed with TCP as an example, and > carried to these protocol once the WG comes to a consensus. Clearly adding the necessary transport functionality to support ConEx needs to be done for each transport. I suspect what this WG will end up doing is giving some guidelines and possibly a canonical TCP example... But that comes further down the line. First off we have to actually publish a couple of initial documents! Toby > > Richard Scheffenegger > > > > > -----Original Message----- > > From: John Leslie [mailto:john@jlc.net] > > Sent: Montag, 27. Juni 2011 17:15 > > To: Scheffenegger, Richard > > Cc: ConEx IETF list > > Subject: Re: [conex] conex marks and tcp > > > > Scheffenegger, Richard wrote: > > > > > > Sorry to bother the group with this question... > > > > Turns out, it's an interesting question... > > > > > The reason I'm asking is that Conex and ECN are very much tied > > together > > > for TCP flows. However, ECN is currently not to be used for non- > data > > > segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] and > > > [RST]). > > > > Certainly, ECN _could_ be used on these; but there's no obvious > > reason > > to -- there's no obvious back-off to be done if congestion is > > experienced. > > > > > However, for a bidirectional session, wouldn't it be beneficial to > > also > > > collect ECN marks (to be fed into Conex) with other types of > segment > > > apart from data segments? > > > > I see no reason that ConEx credit markings couldn't go in a SYN: > > indicating an intent to build an initial credit. It does raise some > > questions about implementation (which seem premature). > > > > Thinking it through, this could play a role in DDoS mitigation -- > > which we've ruled out of the initial presentation. > > > > Thus it doesn't seem appropriate for -concepts-uses; but perhaps > we > > might think of hooks when we discuss abstract-mechanism. These > non-data > > packets are effectively part of the flow; and the ConEx mechanism is > a > > Layer-3 beast which doesn't care how the sender learns of congestion > > experienced. > > > > > That would - at least for TCP - appear to be simpler than trying to > > come > > > up with a new heuristic to detect lost ACKs and use that as source > of > > > Conex marks. > > > > I'm afraid we're stuck considering lost ACKs anyway, though ECN > > marks > > are a better mechanism... > > > > > In addition, ECN-marked segments are supposed to get dropped with > > lower > > > probability too, making features like AckCC more appealing... > > > > I'm not sure there's enough consensus yet on lower-drop- > probability > > for ECN-marked packets. :^( > > > > > Of course, there may be other transports which currently don't > allow > > ECN > > > for certain types of packets; Should the rationale for not having > ECN > > on > > > a global basis be reviewed for Conex enabled stacks? > > > > I'm not sure I understand this question. > > > > -- > > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Mon Jun 27 09:08:18 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAAA11E80C7 for ; Mon, 27 Jun 2011 09:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3YqTJCxkw3C for ; Mon, 27 Jun 2011 09:08:18 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id AF0C311E809B for ; Mon, 27 Jun 2011 09:08:17 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (35.50.22.95.dynamic.jazztel.es [95.22.50.35]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id C43ED9C56FC; Mon, 27 Jun 2011 18:08:13 +0200 (CEST) Message-ID: <4E08AAEC.3080200@it.uc3m.es> Date: Mon, 27 Jun 2011 18:08:12 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Briscoe References: <201106141620.p5EGKj1i027257@bagheera.jungle.bt.co.uk> <4DF792CB.5090207@informatik.uni-tuebingen.de> <201106141803.p5EI3s4Y027835@bagheera.jungle.bt.co.uk> <4DF7C02C.2020505@informatik.uni-tuebingen.de> <201106142145.p5ELjNHN028831@bagheera.jungle.bt.co.uk> <4DF84A1E.5050907@informatik.uni-tuebingen.de> <20110615213941.GM96377@verdi> <201106161219.p5GCJGQj006921@bagheera.jungle.bt.co.uk> <20110616135429.GN96377@verdi> <002d01cc2c44$7ab9d8a0$702d89e0$@com> <201106171738.p5HHcJAc017303@bagheera.jungle.bt.co.uk> <000d01cc2d1a$86ed9ae0$94c8d0a0$@com> <201106231509.p5NF99pk024048@bagheera.jungle.bt.co.uk> <4E06E142.5090300@it.uc3m.es> <201106260926.p5Q9QH2X010040@bagheera.jungle.bt.co.uk> <4E073819.1080304@it.uc3m.es> <201106262004.p5QK4Bfu011371@bagheera.jungle.bt.co.uk> <4E081DC0.3070007@it.uc3m.es> <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <4E088D36.5040806@it.uc3m.es> <201106271516.p5RFGBC2015052@bagheera.jungle.bt.co.uk> In-Reply-To: <201106271516.p5RFGBC2015052@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18226.000 Cc: 'ConEx IETF list' Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:08:18 -0000 what you say makes sense to me. I was just trying to point out the role of the chairs in the process. In particular i was trying to clarify that it is not that the chairs had forced the editors of the document to change the document (hence you should verify with them (us) about adding new stuff), it is that the WG provided feedback on the document and the chairs merely made sure that the feedback was reflected in the doc. That was the feedback we received then and we enforced it. Now the document has evolved. Ship the new version and let's see what the WG thinks about it. If the WGis happy with it, so will we (at least in our role as wg chairs) El 27/06/11 17:16, Bob Briscoe escribió: > Marcelo, > > Thanks - I've gone and read the IETF78 ConEx minutes and been reminded > of the pressure at that time. > > In hindsight I would have pushed back more at the time. It is true > that the use-cases part of concepts-uses should be mechanism > independent, but it would be overly theoretical to describe the > concepts (e.g. downstream congestion-volume) without using mechanisms > as examples. > > We need to constantly remind ourselves that concepts-uses has three > purposes: > - describe the problem(s) > - concepts > - benefits > - deployment arrangements > > (that's four ;) > > We haven't even got on to the problems with discussing deployment > arrangements yet. That will be impossible without introducing > mechanism, but I still think there's a separate role for > abstract-mech, which has all the precise statements about mechanism, > while concepts-uses can treat all the parts as high-level building > blocks. > > > Bob > > At 15:01 27/06/2011, marcelo bagnulo braun wrote: >> El 27/06/11 12:14, Bob Briscoe escribió: >>> The question merely arose because Toby was saying he had attempted >>> to have some specifics on mechanism in concepts-uses before, and >>> he'd been asked to make concepts-uses mechanism-independent by the >>> chairs. >> Let me correct this. The WG input was that this should be removed. >> Please check the minutes from IETF78 proceedings on the use case >> document and the feedback received. The WG chairs we were not stating >> a position on the technical issue, but merely ensuring that the >> feedback received by the WG was reflected in the document. >> >> Regards, marcelo >> >> >>> >>> Bob >>> >>> >>>> Regards, marcelo >>>> >>>> >>>>> Bob >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT Innovate & Design >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From bauer@mit.edu Mon Jun 27 09:18:41 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646B811E80E7 for ; Mon, 27 Jun 2011 09:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHoJnvLYoCar for ; Mon, 27 Jun 2011 09:18:41 -0700 (PDT) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD321F85F2 for ; Mon, 27 Jun 2011 09:18:37 -0700 (PDT) Received: from mail-ew0-f44.google.com ([209.85.215.44]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1QbEWC-0003eE-HN for conex@ietf.org; Mon, 27 Jun 2011 12:18:36 -0400 Received: by ewy19 with SMTP id 19so1913567ewy.31 for ; Mon, 27 Jun 2011 09:18:35 -0700 (PDT) Received: by 10.14.13.70 with SMTP id a46mr4017944eea.166.1309191515098; Mon, 27 Jun 2011 09:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.19.145 with HTTP; Mon, 27 Jun 2011 09:18:05 -0700 (PDT) In-Reply-To: <002501cc34e4$0ef07810$2cd16830$@com> References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> <20110627151440.GG56541@verdi> <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> <002501cc34e4$0ef07810$2cd16830$@com> From: Steve Bauer Date: Mon, 27 Jun 2011 12:18:05 -0400 Message-ID: To: Toby Moncaster Content-Type: text/plain; charset=ISO-8859-1 Cc: ConEx IETF list Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:18:41 -0000 On Mon, Jun 27, 2011 at 12:05 PM, Toby Moncaster wrote: > I seem to recall the authors felt there was a good reason not to implement > it on the SYN packet, but I can't for the life of me recall what it was! See: http://tools.ietf.org/html/rfc5562#section-4.2 There are several reasons why an ECN-Capable codepoint must not be set in the IP header of the initiating TCP SYN packet. First, when the TCP SYN packet is sent, there are no guarantees that the other TCP endpoint (node B in Figure 2) is ECN-Capable, or that it would be able to understand and react if the ECN CE codepoint was set by a congested router. Second, the ECN-Capable codepoint in TCP SYN packets could be misused by malicious clients to "improve" the well-known TCP SYN attack. By setting an ECN-Capable codepoint in TCP SYN packets, a malicious host might be able to inject a large number of TCP SYN packets through a potentially congested ECN-enabled router, congesting it even further. For both these reasons, we continue the restriction that the TCP SYN packet must not have the ECN-Capable codepoint in the IP header set. From wes@mti-systems.com Mon Jun 27 09:29:46 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453FA11E8124 for ; Mon, 27 Jun 2011 09:29:46 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C79+HXm7uha for ; Mon, 27 Jun 2011 09:29:45 -0700 (PDT) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1828111E8122 for ; Mon, 27 Jun 2011 09:29:44 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5RGTfKc013586 for ; Mon, 27 Jun 2011 12:29:44 -0400 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.176.128] ([107.46.176.128:15467] helo=[192.168.9.2]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4F/48-16428-5FFA80E4; Mon, 27 Jun 2011 12:29:41 -0400 Message-ID: <4E08AFF5.4060806@mti-systems.com> Date: Mon, 27 Jun 2011 12:29:41 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Toby Moncaster References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> <20110627151440.GG56541@verdi> <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> <002501cc34e4$0ef07810$2cd16830$@com> In-Reply-To: <002501cc34e4$0ef07810$2cd16830$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'ConEx IETF list' Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:29:46 -0000 On 6/27/2011 12:05 PM, Toby Moncaster wrote: > Speaking personally, I think ConEx certainly should apply to initial packets > in any flow (data or not). As I understand it, the main reason RFC3168 ECN > didn't apply to SYN, SYN-ACK and ACK was because the transports would also > be doing hand-shaking for ECN negotiation. Since then there has been work on > activating ECN for SYN-ACK and ACK packets > (http://tools.ietf.org/html/rfc5562), but that is only experimental. > > I seem to recall the authors felt there was a good reason not to implement > it on the SYN packet, but I can't for the life of me recall what it was! > The reasons why it's not proposed for the SYN are laid out in Section 4.2 of RFC 5562. Basically, there's no guarantee that the other side is ECN-capable, and there may be some potential for misuse in a variation of a SYN flood attack (this could be sketchy, the example given in 5562 doesn't seem very strong to me). For ECN marks in ACK segments, note that RFC 5690 examines a lot of issues for using these for ACK congestion control, which should have similar applicability to using them for conex. -- Wes Eddy MTI Systems From rs@netapp.com Mon Jun 27 09:52:08 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6D221F86C5 for ; Mon, 27 Jun 2011 09:52:04 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnyU0GXChkN2 for ; Mon, 27 Jun 2011 09:52:04 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7DD21F86C3 for ; Mon, 27 Jun 2011 09:52:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,433,1304319600"; d="scan'208";a="261666072" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 27 Jun 2011 09:51:50 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p5RGpo4a017774; Mon, 27 Jun 2011 09:51:50 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jun 2011 18:51:50 +0200 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: Mon, 27 Jun 2011 17:51:47 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F0148D3@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <002501cc34e4$0ef07810$2cd16830$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] conex marks and tcp Thread-Index: Acw03Q5YaCCwfXhrRRm3NYCNXMVEAwAAEsNgAAFDkCAAAWkYwA== References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> <20110627151440.GG56541@verdi> <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> <002501cc34e4$0ef07810$2cd16830$@com> From: "Scheffenegger, Richard" To: "Toby Moncaster" , "John Leslie" X-OriginalArrivalTime: 27 Jun 2011 16:51:50.0360 (UTC) FILETIME=[82844580:01CC34EA] Cc: ConEx IETF list Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:52:08 -0000 Hi Tony, Not to have ECN on [SYN] was to mitigate DDoS attacks apparently. OTOH, DDoS packets can not be expected to not bend some rules. If ECN-marked packets are seen as getting delivered with higher likelihood, a DDoS would probably use that. And I don't know a stack that would throw away ECN-marked SYNs (but a firewall rule would be easy to set up though, while under attack). Yes, I read Bob's drafts; for the most part, the exact semantics of the ECN signaling in TCP are changed, but the Re-ECN draft was a little bit ambiguous when it comes to pure ACKs (or other non-SYN, non-data segments). Effectively, the "which packets carry ECN" aligns with RFC3168, with the exception of all SYNs... The text effectively allows ECN for [SYN] and [SYN, ACK], but always talks about "data" segments in section 6 ff. Table 6 then shows "RECT" set for pure ACKs, too (line 8 and 11).=20 In section 6.1.5 however, the text forbade ECN marking for retransmissions, and non-data segments (pure ACKs, window probes, FIN, RST with no data)... This contradicts the example in table 6... A missing thorough security analysis being quoted as the reasoning, but the stated goal then was also, to have all TCP segments marked re-ecn (=3DECN) capable. In effect, reECN seems to align with an approach to allow ECN on *every* TCP segment. From my point of view, with Conex that would also be the natural thing to do. Just wanted to clarify this, so that it doesn't get lost when the interaction with TCP is to be specified for a canonical TCP implementation. The mentioned security analysis will need to be done prior to defining that Conex/TCP interaction though. Richard Scheffenegger > -----Original Message----- > From: Toby Moncaster [mailto:toby@moncaster.com] > Sent: Montag, 27. Juni 2011 18:06 > To: Scheffenegger, Richard; 'John Leslie' > Cc: 'ConEx IETF list' > Subject: RE: [conex] conex marks and tcp >=20 > Speaking personally, I think ConEx certainly should apply to initial > packets > in any flow (data or not). As I understand it, the main reason RFC3168 > ECN > didn't apply to SYN, SYN-ACK and ACK was because the transports would > also > be doing hand-shaking for ECN negotiation. Since then there has been > work on > activating ECN for SYN-ACK and ACK packets > (http://tools.ietf.org/html/rfc5562), but that is only experimental. >=20 > I seem to recall the authors felt there was a good reason not to > implement > it on the SYN packet, but I can't for the life of me recall what it > was! >=20 > Inline... >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > Of Scheffenegger, Richard > > Sent: 27 June 2011 16:33 > > To: John Leslie > > Cc: ConEx IETF list > > Subject: Re: [conex] conex marks and tcp > > > > Hi John, > > > > yes, this question is jumping the current discussions on the conex > > list, > > and really belongs in the valley of implementation details :) > > > > My understanding was, that lost *data* segments will provide the > input > > signal for conex, short of ECN. That is a relatively easy metric to > > come > > by within TCP, whereas lost (+delayed) pure ACKs aren't really > > accounted > > in TCP stacks. Besides, the congestion information conveyed by lost > > pure > > ACKs (no data) is at the wrong end of the connection, and TCP will > not > > convey that information back to the sender of the ACKs >=20 >=20 > OK that is certainly getting into finer details of implementation and > mechanism! One argument goes that every sender (and that includes > senders > that are just ACKing received data) should respond to every byte of > congestion they see. But as you say, ACKs aren't ACKed (otherwise you'd > get > into an endless cycle) >=20 > > (the receiver of > > the data stream at this point in time), unless the TCP ECN mechanism > is > > used. TCP ECN works bidirectional, so for TCP at least, it appears > that > > Conex would give a high incentive to have all TCP segments > > ECN-capable.... >=20 > Yep - ConEx certainly should give a strong incentive to enable ECN for > both > the end-systems AND the networks - there is already evidence that it > would > benefit end-systems, but up till now it has only had marginal benefits > for > the network, hence lack of wide deployment (network operators are not > renowned for their altruism) >=20 > > > > Using RFC3168 ECN marking with TCP however, seems to make things > > unnecessary complicated. Whenever the data direction of a TCP flow > > changes, the Conex machinery may need to be restarted (because > > information learned before may be long outdated). With always ECN > > segments, Conex would maintain a good understanding of the network > > congestion state, and not need to start from scratch... >=20 > Have you read the earlier documents about re-ECN with TCP? > (http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09) Although > re-ECN uses the IP part of the ECN mechanism it completely replaced the > TCP > part >=20 > > > > > > > > My last remark was with respect to DCCP, SCTP, RTTP and other > transport > > protocols that I'm not really familiar with; they may have similar > > limitations on their use of ECN-capable packets as TCP, thus similar > > implications. Just to not leave them out completely - but I guess the > > Conex/ECN interaction can be discussed with TCP as an example, and > > carried to these protocol once the WG comes to a consensus. >=20 > Clearly adding the necessary transport functionality to support ConEx > needs > to be done for each transport. I suspect what this WG will end up doing > is > giving some guidelines and possibly a canonical TCP example... But that > comes further down the line. First off we have to actually publish a > couple > of initial documents! >=20 > Toby >=20 >=20 > > > > Richard Scheffenegger > > > > > > > > > -----Original Message----- > > > From: John Leslie [mailto:john@jlc.net] > > > Sent: Montag, 27. Juni 2011 17:15 > > > To: Scheffenegger, Richard > > > Cc: ConEx IETF list > > > Subject: Re: [conex] conex marks and tcp > > > > > > Scheffenegger, Richard wrote: > > > > > > > > Sorry to bother the group with this question... > > > > > > Turns out, it's an interesting question... > > > > > > > The reason I'm asking is that Conex and ECN are very much tied > > > together > > > > for TCP flows. However, ECN is currently not to be used for non- > > data > > > > segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] > and > > > > [RST]). > > > > > > Certainly, ECN _could_ be used on these; but there's no obvious > > > reason > > > to -- there's no obvious back-off to be done if congestion is > > > experienced. > > > > > > > However, for a bidirectional session, wouldn't it be beneficial > to > > > also > > > > collect ECN marks (to be fed into Conex) with other types of > > segment > > > > apart from data segments? > > > > > > I see no reason that ConEx credit markings couldn't go in a SYN: > > > indicating an intent to build an initial credit. It does raise some > > > questions about implementation (which seem premature). > > > > > > Thinking it through, this could play a role in DDoS mitigation - > - > > > which we've ruled out of the initial presentation. > > > > > > Thus it doesn't seem appropriate for -concepts-uses; but perhaps > > we > > > might think of hooks when we discuss abstract-mechanism. These > > non-data > > > packets are effectively part of the flow; and the ConEx mechanism > is > > a > > > Layer-3 beast which doesn't care how the sender learns of > congestion > > > experienced. > > > > > > > That would - at least for TCP - appear to be simpler than trying > to > > > come > > > > up with a new heuristic to detect lost ACKs and use that as > source > > of > > > > Conex marks. > > > > > > I'm afraid we're stuck considering lost ACKs anyway, though ECN > > > marks > > > are a better mechanism... > > > > > > > In addition, ECN-marked segments are supposed to get dropped with > > > lower > > > > probability too, making features like AckCC more appealing... > > > > > > I'm not sure there's enough consensus yet on lower-drop- > > probability > > > for ECN-marked packets. :^( > > > > > > > Of course, there may be other transports which currently don't > > allow > > > ECN > > > > for certain types of packets; Should the rationale for not having > > ECN > > > on > > > > a global basis be reviewed for Conex enabled stacks? > > > > > > I'm not sure I understand this question. > > > > > > -- > > > John Leslie > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex From ingemar.s.johansson@ericsson.com Mon Jun 27 22:00:36 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336B121F85FA for ; Mon, 27 Jun 2011 22:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncnyYBJG3DI8 for ; Mon, 27 Jun 2011 22:00:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A09E421F84E0 for ; Mon, 27 Jun 2011 22:00:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4c-4e095fec2081 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.26.20773.CEF590E4; Tue, 28 Jun 2011 07:00:28 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.23]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 28 Jun 2011 07:00:28 +0200 From: Ingemar Johansson S To: "Scheffenegger, Richard" , Toby Moncaster , John Leslie Date: Tue, 28 Jun 2011 07:00:27 +0200 Thread-Topic: [conex] conex marks and tcp Thread-Index: Acw0/MJwHBfLJv4ZRje9aD51vwebzAAUgL0A Message-ID: References: <201106271014.p5RAEpuL013877@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0F014809@LDCMVEXC1-PRD.hq.netapp.com> <20110627151440.GG56541@verdi> <5FDC413D5FA246468C200652D63E627A0F01486F@LDCMVEXC1-PRD.hq.netapp.com> <002501cc34e4$0ef07810$2cd16830$@com> <5FDC413D5FA246468C200652D63E627A0F0148D3@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F0148D3@LDCMVEXC1-PRD.hq.netapp.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ConEx IETF list Subject: Re: [conex] conex marks and tcp X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 05:00:36 -0000 Hi ECN+ (as it is also called) is discussed in this paper http://www.cs.northwestern.edu/~akuzma/doc/ecn.pdf ECN+ was recently discussed in the buferbloat list and there was a mention = of some issues with it, no details though. https://lists.bufferbloat.net/pipermail/bloat/2011-March/000365.html /Ingemar > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com]=20 > Sent: den 27 juni 2011 18:52 > To: Toby Moncaster; John Leslie > Cc: ConEx IETF list > Subject: Re: [conex] conex marks and tcp >=20 > Hi Tony, >=20 > Not to have ECN on [SYN] was to mitigate DDoS attacks=20 > apparently. OTOH, DDoS packets can not be expected to not=20 > bend some rules. If ECN-marked packets are seen as getting=20 > delivered with higher likelihood, a DDoS would probably use=20 > that. And I don't know a stack that would throw away=20 > ECN-marked SYNs (but a firewall rule would be easy to set up=20 > though, while under attack). >=20 >=20 > Yes, I read Bob's drafts; for the most part, the exact=20 > semantics of the ECN signaling in TCP are changed, but the=20 > Re-ECN draft was a little bit ambiguous when it comes to pure=20 > ACKs (or other non-SYN, non-data segments). Effectively, the=20 > "which packets carry ECN" aligns with RFC3168, with the=20 > exception of all SYNs... >=20 >=20 > The text effectively allows ECN for [SYN] and [SYN, ACK], but=20 > always talks about "data" segments in section 6 ff. >=20 > Table 6 then shows "RECT" set for pure ACKs, too (line 8 and 11).=20 >=20 > In section 6.1.5 however, the text forbade ECN marking for=20 > retransmissions, and non-data segments (pure ACKs, window=20 > probes, FIN, RST with no data)... This contradicts the=20 > example in table 6... A missing thorough security analysis=20 > being quoted as the reasoning, but the stated goal then was=20 > also, to have all TCP segments marked re-ecn > (=3DECN) capable. >=20 >=20 >=20 > In effect, reECN seems to align with an approach to allow ECN=20 > on *every* TCP segment. From my point of view, with Conex=20 > that would also be the natural thing to do. Just wanted to=20 > clarify this, so that it doesn't get lost when the=20 > interaction with TCP is to be specified for a canonical TCP=20 > implementation. The mentioned security analysis will need to=20 > be done prior to defining that Conex/TCP interaction though. >=20 > Richard Scheffenegger >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Toby Moncaster [mailto:toby@moncaster.com] > > Sent: Montag, 27. Juni 2011 18:06 > > To: Scheffenegger, Richard; 'John Leslie' > > Cc: 'ConEx IETF list' > > Subject: RE: [conex] conex marks and tcp > >=20 > > Speaking personally, I think ConEx certainly should apply=20 > to initial=20 > > packets in any flow (data or not). As I understand it, the=20 > main reason=20 > > RFC3168 ECN didn't apply to SYN, SYN-ACK and ACK was because the=20 > > transports would also be doing hand-shaking for ECN=20 > negotiation. Since=20 > > then there has been work on activating ECN for SYN-ACK and=20 > ACK packets=20 > > (http://tools.ietf.org/html/rfc5562), but that is only experimental. > >=20 > > I seem to recall the authors felt there was a good reason not to=20 > > implement it on the SYN packet, but I can't for the life of=20 > me recall=20 > > what it was! > >=20 > > Inline... > >=20 > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > > Behalf > > > Of Scheffenegger, Richard > > > Sent: 27 June 2011 16:33 > > > To: John Leslie > > > Cc: ConEx IETF list > > > Subject: Re: [conex] conex marks and tcp > > > > > > Hi John, > > > > > > yes, this question is jumping the current discussions on=20 > the conex=20 > > > list, and really belongs in the valley of implementation=20 > details :) > > > > > > My understanding was, that lost *data* segments will provide the > > input > > > signal for conex, short of ECN. That is a relatively easy=20 > metric to=20 > > > come by within TCP, whereas lost (+delayed) pure ACKs=20 > aren't really=20 > > > accounted in TCP stacks. Besides, the congestion information=20 > > > conveyed by lost pure ACKs (no data) is at the wrong end of the=20 > > > connection, and TCP will > > not > > > convey that information back to the sender of the ACKs > >=20 > >=20 > > OK that is certainly getting into finer details of=20 > implementation and=20 > > mechanism! One argument goes that every sender (and that includes=20 > > senders that are just ACKing received data) should respond to every=20 > > byte of congestion they see. But as you say, ACKs aren't ACKed=20 > > (otherwise > you'd > > get > > into an endless cycle) > >=20 > > > (the receiver of > > > the data stream at this point in time), unless the TCP=20 > ECN mechanism > > is > > > used. TCP ECN works bidirectional, so for TCP at least, it appears > > that > > > Conex would give a high incentive to have all TCP segments=20 > > > ECN-capable.... > >=20 > > Yep - ConEx certainly should give a strong incentive to=20 > enable ECN for=20 > > both the end-systems AND the networks - there is already=20 > evidence that=20 > > it would benefit end-systems, but up till now it has only=20 > had marginal=20 > > benefits for the network, hence lack of wide deployment (network=20 > > operators are not renowned for their altruism) > >=20 > > > > > > Using RFC3168 ECN marking with TCP however, seems to make things=20 > > > unnecessary complicated. Whenever the data direction of a=20 > TCP flow=20 > > > changes, the Conex machinery may need to be restarted (because=20 > > > information learned before may be long outdated). With always ECN=20 > > > segments, Conex would maintain a good understanding of=20 > the network=20 > > > congestion state, and not need to start from scratch... > >=20 > > Have you read the earlier documents about re-ECN with TCP? > > (http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09) > Although > > re-ECN uses the IP part of the ECN mechanism it completely replaced > the > > TCP > > part > >=20 > > > > > > > > > > > > My last remark was with respect to DCCP, SCTP, RTTP and other > > transport > > > protocols that I'm not really familiar with; they may=20 > have similar=20 > > > limitations on their use of ECN-capable packets as TCP,=20 > thus similar=20 > > > implications. Just to not leave them out completely - but I guess > the > > > Conex/ECN interaction can be discussed with TCP as an=20 > example, and=20 > > > carried to these protocol once the WG comes to a consensus. > >=20 > > Clearly adding the necessary transport functionality to=20 > support ConEx=20 > > needs to be done for each transport. I suspect what this WG=20 > will end=20 > > up > doing > > is > > giving some guidelines and possibly a canonical TCP example... But > that > > comes further down the line. First off we have to actually=20 > publish a=20 > > couple of initial documents! > >=20 > > Toby > >=20 > >=20 > > > > > > Richard Scheffenegger > > > > > > > > > > > > > -----Original Message----- > > > > From: John Leslie [mailto:john@jlc.net] > > > > Sent: Montag, 27. Juni 2011 17:15 > > > > To: Scheffenegger, Richard > > > > Cc: ConEx IETF list > > > > Subject: Re: [conex] conex marks and tcp > > > > > > > > Scheffenegger, Richard wrote: > > > > > > > > > > Sorry to bother the group with this question... > > > > > > > > Turns out, it's an interesting question... > > > > > > > > > The reason I'm asking is that Conex and ECN are very much tied > > > > together > > > > > for TCP flows. However, ECN is currently not to be=20 > used for non- > > > data > > > > > segments (ie. [SYN], [SYN,ACK] and pure [ACK], as=20 > well as [FIN] > > and > > > > > [RST]). > > > > > > > > Certainly, ECN _could_ be used on these; but there's=20 > no obvious=20 > > > > reason to -- there's no obvious back-off to be done if=20 > congestion=20 > > > > is experienced. > > > > > > > > > However, for a bidirectional session, wouldn't it be=20 > beneficial > > to > > > > also > > > > > collect ECN marks (to be fed into Conex) with other types of > > > segment > > > > > apart from data segments? > > > > > > > > I see no reason that ConEx credit markings couldn't go in a > SYN: > > > > indicating an intent to build an initial credit. It does raise > some > > > > questions about implementation (which seem premature). > > > > > > > > Thinking it through, this could play a role in DDoS=20 > mitigation > - > > - > > > > which we've ruled out of the initial presentation. > > > > > > > > Thus it doesn't seem appropriate for -concepts-uses; but > perhaps > > > we > > > > might think of hooks when we discuss abstract-mechanism. These > > > non-data > > > > packets are effectively part of the flow; and the ConEx=20 > mechanism > > is > > > a > > > > Layer-3 beast which doesn't care how the sender learns of > > congestion > > > > experienced. > > > > > > > > > That would - at least for TCP - appear to be simpler=20 > than trying > > to > > > > come > > > > > up with a new heuristic to detect lost ACKs and use that as > > source > > > of > > > > > Conex marks. > > > > > > > > I'm afraid we're stuck considering lost ACKs anyway,=20 > though ECN=20 > > > > marks are a better mechanism... > > > > > > > > > In addition, ECN-marked segments are supposed to get dropped > with > > > > lower > > > > > probability too, making features like AckCC more appealing... > > > > > > > > I'm not sure there's enough consensus yet on lower-drop- > > > probability > > > > for ECN-marked packets. :^( > > > > > > > > > Of course, there may be other transports which currently don't > > > allow > > > > ECN > > > > > for certain types of packets; Should the rationale for not > having > > > ECN > > > > on > > > > > a global basis be reviewed for Conex enabled stacks? > > > > > > > > I'm not sure I understand this question. > > > > > > > > -- > > > > John Leslie > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex >=20 >=20 > = From karagian@cs.utwente.nl Thu Jun 30 23:39:25 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A63D21F882B for ; Thu, 30 Jun 2011 23:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcHwP-Omk-X3 for ; Thu, 30 Jun 2011 23:39:24 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 07EF021F84F5 for ; Thu, 30 Jun 2011 23:39:23 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p616bpgs010668; Fri, 1 Jul 2011 08:37:51 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 01 Jul 2011 06:39:23 +0000 To: "SCHARF, Michael" , "Bob Briscoe" Date: Fri, 01 Jul 2011 06:39:22 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <0RLmKQ20.1309502362.2233540.karagian@ewi.utwente.nl> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAC@SLFSNX.rcs.alcatel-research.de> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 01 Jul 2011 08:38:01 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 06:39:25 -0000 Hi Bob, Hi Michael, After discussing this issue with Dimitri (also a co-author of RFC 6077) I understood that the problem related to the need of network flow state=20 in multi-domain scenarios, during congestion control, comes from the "non-cooperative" behavior and untrustable nature of the information: whether congestion control information exchanges are "implicit" or "explicit" and "rate-based" vs "indication/marks" it doesn't actually matter: enforcement at the level were the information is referring to/referrent (can be per flow or per aggregate or other) will be performed at domain boundaries. Meaning that domain edges do never trigger any action from "external" information that is not verifiable (BGP is the only exception but we would speak at the routing level here). What RFC 6077 actually mentions wrt to scalability is that if signaling is performed on a per flow state basis it will in addition impact scaling of domain edges. Best regards, Georgios On 6/26/2011, "SCHARF, Michael" wrote: >Georgios, Bob, > >I've not followed this discussion. But as another author of RFC 6077 I >want to back Bob's explanation concerning the context. Those sentences >indeed discuss open issues in case that the network performs flow-level >congestion control (XCP, RCP, etc.). > >Michael > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]=20 >> On Behalf Of Bob Briscoe >> Sent: Sunday, June 26, 2011 11:50 AM >> To: Georgios Karagiannis >> Cc: conex@ietf.org >> Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text >>=20 >> Georgios, >>=20 >> The context of those sentences in RFC6077 (which incidentally=20 >> I wrote), was to prove that *if* the network wants to do=20 >> congestion control, claims that it can do this without flow=20 >> state (e.g. with >> XCP/RCP) overlook the need for inter-domain policing, which=20 >> will require flow state. >>=20 >> The statement about flow state wasn't intended to be taken=20 >> out of context as a general statement that identifying flows=20 >> is always unnecessary. It's only in the context where the=20 >> network is already trying to control congestion at the flow level. >>=20 >> [Anyway, in general (but not in this case) just because a=20 >> previous IRTF document (RFC6077) says something is=20 >> impossible, doesn't mean a later IETF doc cannot standardise=20 >> something that makes it possible.] >>=20 >>=20 >> Bob >>=20 >> At 23:55 25/06/2011, Georgios Karagiannis wrote: >> >Hi Bob, >> > >> >Sorry for the delay on sending comments! >> > >> >I have a comment regarding the following paragraph: >> > >> > > With ConEx there is no need for the network provider=20 >> to identify >> > > specific applications or behaviours at the flow level,=20 >> because the >> > > relevant bulk congestion information is revealed at the network >> > > layer. Also, because ConEx information is added=20 >> explicitly at the IP >> > > layer, it is visible to provider and consumer alike. Therefore >> > > traffic contracts or acceptable use policies can be=20 >> based on a metric >> > > that is transparent to both parties and is sufficient to manage >> > > traffic without extra non-transparent wriggle-room and caveats. >> > >> >In the paragrah above it is mentioned that the network provider to=20 >> >identify specific applications or behaviours at the flow=20 >> level, because=20 >> >the relevant bulk congestion information is revealed at the network=20 >> >layer. >> > >> >However, according to RFC 6077, in multi-domain scenarios,=20 >> due to the=20 >> >non-cooperative nature of multi-domain environments, it=20 >> seems unlikely=20 >> >that network flow state could be avoided (up to a certain extend)=20 >> >given the network's per-packet flow rate instructions that=20 >> would need=20 >> >to be compared against variations in the actual flow rate, which is=20 >> >inherently not a per-packet metric. >> > >> >For RFC 6077, see: >> >http://www.rfc-editor.org/rfc/rfc6077.txt >> > >> >Is it possible to explain in the draft how the congestion control=20 >> >related issues associated with multi-domain scenarios=20 >> discussed in RFC=20 >> >6077 are solved/worked out? >> > >> >Best regards, >> >Georgios >> > >> > >> > >> > >> >On 6/14/2011, "Bob Briscoe" wrote: >> > >> > >ConEx folks, >> > > >> > >After the last IETF in Prague, we agreed to work on a revised=20 >> > >draft-ietf-conex-concepts-uses. We're planning on using a=20 >> lot of the=20 >> > >text as is, but we suggested that the Introduction needed=20 >> a complete=20 >> > >re-write. Below is our joint proposal. >> > > >> > >Please bash. >> > > >> > >Rationale for this Introduction: >> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> > >* The main change is a shift to the main target use-case=20 >> in the body=20 >> > >of the document: traffic management, leaving defining=20 >> congestion etc=20 >> > >to the definitions and concepts section (section 2). >> > >* Introduce enough of the solution to allow the reader to grasp >> > the main logic. >> > >* Introduce one primary use and mention there are others - to keep=20 >> > >focused but hint at breadth. >> > >* Start to weave in some benefits bullet points=20 >> (transparency, neutrality). >> > >* Hint at controversies like the over-provisioning issue=20 >> in the first=20 >> > >para, but leave addressing this to later, when we can go into the=20 >> > >subject properly. >> > > >> > > >> > > >> >=20 >> >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >> > >\ >> > >1. Introduction >> > > >> > > The power of Internet technology comes from multiplexing shared >> > > capacity with packets rather than circuits. Network operators >> > > usually provide sufficient capacity, but whenever too=20 >> much packet >> > > load meets too little shared capacity, congestion results. >> > > Congestion appears as either increased delay, missing=20 >> packets or >> > > packets explicitly marked with ECN [RFC3168]. The=20 >> classic Internet >> > > architecture is arranged so that receivers detect such signs of >> > > congestion and feed them back end-to-end. Then, ideally, most >> > > senders reduce their rate in response. >> > > >> > > The purpose of this document is to motivate a new=20 >> congestion exposure >> > > (ConEx) field at the IP layer. The idea is to add a=20 >> third pass to >> > > the feedback loop so that the sender can relay=20 >> congestion information >> > > back into the internetwork layer, exposing the level=20 >> of congestion >> > > the sender expects packets to experience along their whole path >> > > (Figure 1). Then certain network nodes can use this=20 >> new information >> > > at the IP layer, for example as input to traffic management. >> > > >> > > ,---------. =20 >> ,---------. >> > > |Transport| =20 >> |Transport| >> > > | Sender | =20 >> |Receiver | >> > > | =20 >> |<=3D=3DFeedback=3DPath=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<| | >> > > | ,---|<--Transport Layer returned Congestion=20 >> Signal-<|<--. | >> > > | | | =20 >> | | | >> > > | | | =20 >> | | | >> > > | | | ,-----------. =20 >> | | | >> > > | | | |(Congested)| =20 >> | | | >> > > | | |>=3DData=3DPath=3D>| Network =20 >> |>=3D=3D=3D=3D=3DData=3DPath=3D=3D=3D=3D=3D>| | | >> > > | | | | Device =20 >> |>-Congestion-Signal->|---' | >> > > | | | `-----------' =20 >> | | >> > > | `-->|>---------(new) IP layer ConEx=20 >> Signal--------->| | >> > > | | (Carried in Data Packet Headers) =20 >> | | >> > > `---------' =20 >> `---------' >> > > >> > > Figure 1: Where the ConEx Protocol Fits in the Internet=20 >> > > Architecture >> > > >> > > This document serves as the entry point to the set of ConEx >> > > documentation, giving the 'why' rather than the 'how'.=20 >> A companion >> > > document outlines the ConEx protocol mechanism=20 >> [ConEx-Abstract-Mech]. >> > > >> > > The main aim of ConEx is to support evolution of=20 >> alternatives to the >> > > proliferation of traffic management solutions that are over- >> > > constraining, non-transparent and often not=20 >> application-neutral. >> > > Traffic management ought to be able to leave end=20 >> systems free to >> > > choose how to behave without undue interference, while=20 >> simultaneously >> > > satisfying the main concern of network operators; to=20 >> control traffic >> > > from some users that excessively limits the freedoms of others. >> > > >> > > Freedoms only actually collide when shared capacity becomes >> > > congested--when a link is full so that a greater share=20 >> for one user >> > > would necessarily leave less for someone else. Current traffic >> > > management solutions typically limit volume or=20 >> bit-rate in order to >> > > reduce the likelihood of congestion--limiting one=20 >> thing in the hope >> > > it might limit another. However, there is no real=20 >> need to count >> > > volume that is sent when there is no congestion, and=20 >> there is no real >> > > need to limit bit-rate when there is no congestion. >> > > >> > > ConEx markings on packets add the missing information network >> > > operators need to get a handle on congestion itself. =20 >> Then they can >> > > directly limit and control traffic based on how much=20 >> it contributes >> > > to congestion and leave traffic unconstrained if it=20 >> doesn't cause >> > > congestion. The idea is for the operator to be able=20 >> to count and >> > > control the bulk volume or bit-rate of packets marked=20 >> for congestion >> > > and disregard packets not contributing to congestion. >> > > >> > > With ConEx there is no need for the network provider=20 >> to identify >> > > specific applications or behaviours at the flow level,=20 >> because the >> > > relevant bulk congestion information is revealed at the network >> > > layer. Also, because ConEx information is added=20 >> explicitly at the IP >> > > layer, it is visible to provider and consumer alike. Therefore >> > > traffic contracts or acceptable use policies can be=20 >> based on a metric >> > > that is transparent to both parties and is sufficient to manage >> > > traffic without extra non-transparent wriggle-room and caveats. >> > > >> > > In summary, ConEx is designed to make it simple to do traffic >> > > management that is transparent, neutral and not=20 >> over-constrained. >> > > Although there is no implication that network=20 >> operators ought to >> > > provide such an unconstrained, transparent, neutral service, it >> > > certainly should not be impossible and ideally it should be the >> > > simplest service to provide. >> > > >> > > The IP layer is intended to engender new applications=20 >> and behaviours >> > > and to work over all existing and new lower layer technologies. >> > > ConEx is a generative technology in this vein, with a range of >> > > potential uses. This document focuses initially on traffic >> > > management before widening out to introduce some=20 >> additional important >> > > uses for ConEx as well as brifly mentioning a few others. >> >=20 >> >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >> > >\ >> > > >> > > >> > >Bob Briscoe & Rich Woundy >> > > >> > > >> > > >> > >_______________________________________________ >> > >conex mailing list >> > >conex@ietf.org >> > >https://www.ietf.org/mailman/listinfo/conex >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design=20 >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >>=20