From bob.briscoe@bt.com Mon Jul 4 08:02:48 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 48AFA1F0C5C for ; Mon, 4 Jul 2011 08:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 4-KubKumcTpN for ; Mon, 4 Jul 2011 08:02:47 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 84BFB1F0C52 for ; Mon, 4 Jul 2011 08:02:46 -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); Mon, 4 Jul 2011 16:02:45 +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, 4 Jul 2011 16:02:44 +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 1309791763682; Mon, 4 Jul 2011 16:02:43 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.131.208]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p64F2cdw008542; Mon, 4 Jul 2011 16:02:38 +0100 Message-Id: <201107041502.p64F2cdw008542@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Jul 2011 16:02:27 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: <0RLmKQ20.1309502362.2233540.karagian@ewi.utwente.nl> References: <133D9897FB9C5E4E9DF2779DC91E947C0607BAAC@SLFSNX.rcs.alcatel-research.de> <0RLmKQ20.1309502362.2233540.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: 04 Jul 2011 15:02:44.0627 (UTC) FILETIME=[6DD8EE30:01CC3A5B] 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: Mon, 04 Jul 2011 15:02:48 -0000 Georgios, Yes, it's true that domains wouldn't act on unverifiable information. ConEx is designed to solve that problem; to provide downstream congestion measurements at domain boundaries that are verifiable and that can be used in bulk without per-flow processing or state. To achieve that, unfortunately we still need the ConEx audit function, which no-one has yet been able to do without per-flow state. However, very importantly: - per-flow ConEx audit is only necessary at the last egress edge of the internetwork. Every flow does not need to be checked at borders. - ConEx audit does not aim to control the rate behaviour of flows, it is solely a per-flow information check. This means no-one needs to define how individual flows should behave, which is an important achievement. ConEx audit checks on a per-flow basis that signalling of expected congestion is no less than actual congestion. This ensures the integrity of the ConEx information so that it can be used for traffic management in bulk, e.g at domain boundaries or at the boundary with the consumer at the sender end. (Of course, a network operator could still choose to do per-flow traffic management. However if their goal is to control traffic cost or to control one consumer's impact on others it is sufficient for a network operator to use ConEx information to manage traffic behaviour in bulk, not per flow.) Bob At 07:39 01/07/2011, Georgios Karagiannis wrote: >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 >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] > >> 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 > >> > >> 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 > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > >> ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Mon Jul 4 11:45: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 DE57E1F0CAE for ; Mon, 4 Jul 2011 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 GQVHT6eqpkDD for ; Mon, 4 Jul 2011 11:45:08 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2F71F0CAD for ; Mon, 4 Jul 2011 11:45:08 -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 p64IhTN1006358; Mon, 4 Jul 2011 20:43:29 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 04 Jul 2011 18:45:06 +0000 To: "Bob Briscoe" Date: Mon, 04 Jul 2011 18:45:05 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107041502.p64F2cdw008542@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]); Mon, 04 Jul 2011 20:43:39 +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: Mon, 04 Jul 2011 18:45:10 -0000 Hi Bob, Please see in line! On 7/4/2011, "Bob Briscoe" wrote: >Georgios, > >Yes, it's true that domains wouldn't act on unverifiable information. > >ConEx is designed to solve that problem; to provide downstream >congestion measurements at domain boundaries that are verifiable and >that can be used in bulk without per-flow processing or state. > >To achieve that, unfortunately we still need the ConEx audit >function, which no-one has yet been able to do without per-flow >state.=20 Georgios: Is it not necessay to use a policer? > However, very importantly: >- per-flow ConEx audit is only necessary at the last egress edge of >the internetwork. Every flow does not need to be checked at borders. Georgios: Okay, but I assume that whenever the congestion rate needs to be measured, then a per-flow state is needed. Please check the following draft that somehow tries to describe this issue: http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt >- ConEx audit does not aim to control the rate behaviour of flows, it >is solely a per-flow information check. This means no-one needs to >define how individual flows should behave, which is an important achievement= . Georgios: okay, but I assume that when a policer is used, then the control of the rate behaviour will be affected! > >ConEx audit checks on a per-flow basis that signalling of expected >congestion is no less than actual congestion. This ensures the >integrity of the ConEx information so that it can be used for traffic >management in bulk, e.g at domain boundaries or at the boundary with >the consumer at the sender end. > >(Of course, a network operator could still choose to do per-flow >traffic management. However if their goal is to control traffic cost >or to control one consumer's impact on others it is sufficient for a >network operator to use ConEx information to manage traffic behaviour >in bulk, not per flow.) Georgios: Do you mean that Conex will not require the use of a per-flow policer? Best regards, Georgios > > > >Bob > >At 07:39 01/07/2011, Georgios Karagiannis wrote: >>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 >>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] >> >> 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 >> >> >> >> 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: >> >> > >=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. >> >> > > >> >> > > 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 >> >> >> >> _______________________________________________ >> >> conex mailing list >> >> conex@ietf.org >> >> https://www.ietf.org/mailman/listinfo/conex >> >> > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Jul 5 02:11: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 22D5921F85E6 for ; Tue, 5 Jul 2011 02:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dddzc8jWLy1 for ; Tue, 5 Jul 2011 02:11:43 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF3121F86B4 for ; Tue, 5 Jul 2011 02:11:42 -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); Tue, 5 Jul 2011 10:11:40 +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, 5 Jul 2011 10:11:40 +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 1309857097567; Tue, 5 Jul 2011 10:11:37 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.80.176]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p659BXY8013753; Tue, 5 Jul 2011 10:11:34 +0100 Message-Id: <201107050911.p659BXY8013753@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Jul 2011 10:11:33 +0100 To: Georgios Karagiannis , Mikael Abrahamsson From: Bob Briscoe In-Reply-To: References: <201107041502.p64F2cdw008542@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_61457000==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 05 Jul 2011 09:11:40.0111 (UTC) FILETIME=[8CD49DF0:01CC3AF3] 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: Tue, 05 Jul 2011 09:11:46 -0000 --=====================_61457000==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, [Mike, I've also directed this response to you - please see "{Note 1}" inline that answers a question I recall you asked months ago. I don't think I ever answered it - probably got distracted by something.] At 19:45 04/07/2011, Georgios Karagiannis wrote: >Hi Bob, > >Please see in line! > >On 7/4/2011, "Bob Briscoe" wrote: > > >Georgios, > > > >Yes, it's true that domains wouldn't act on unverifiable information. > > > >ConEx is designed to solve that problem; to provide downstream > >congestion measurements at domain boundaries that are verifiable and > >that can be used in bulk without per-flow processing or state. > > > >To achieve that, unfortunately we still need the ConEx audit > >function, which no-one has yet been able to do without per-flow > >state. > >Georgios: Is it not necessay to use a policer? Three points: a) I assume you are using the terms 'policer' and 'audit function' as in conex-abstract-mech? b) It isn't necessary to use a policer between networks. Indeed, I would not recommend a policer between two networks that both use ConEx info to protect their respective networks.{Note 1} A traffic contract with penalties for sending too much congestion will be sufficient. c) A policer does not need to use flow-state. It can act on the bulk of traffic passing from the consumer to their ingress network. > > However, very importantly: > >- per-flow ConEx audit is only necessary at the last egress edge of > >the internetwork. Every flow does not need to be checked at borders. > >Georgios: Okay, but I assume that whenever the congestion rate needs to >be measured, then a per-flow state is needed. Not at all. Just like bit-rate, congestion rate is a metric that can measure any granularity: flows, aggregates or all the traffic on a link. ConEx markings are designed to correctly characterise the amount of traffic causing congestion at any granularity - without having to measure at finer granularities and add them up. For instance, a "congestion token bucket policer" measures the congestion rate and it can be applied at the granularity of a link without looking at flows. Just like a normal token bucket can be applied without looking at flows. Whenever a ConEx marked packet arrives, tokens are removed from this bucket, without caring about flows. >Please check the following >draft that somehow tries to describe this issue: >http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt Ah! Your draft *assumes* that the congestion rate is being measured per flow, then essentially it says it would be complex to measure the congestion rate per flow. I think you've seriously misunderstood. Although ConEx *could* be used to make sure individual flows conform to the TCP behaviour, that is neither necessary nor the goal. In fact it is a non-goal.{Note 2} The argument is that it would actually be very wrong to try to get flows to conform to the TCP behaviour. Embedding such policers in the network would prevent future evolution of better congestion controls. I will add this to the list of misconceptions in conex-uses. > >- ConEx audit does not aim to control the rate behaviour of flows, it > >is solely a per-flow information check. This means no-one needs to > >define how individual flows should behave, which is an important > achievement. > >Georgios: okay, but I assume that when a policer is used, then the >control of the rate behaviour will be affected! Of course. But if it is a bulk policer, it only limits the bulk rate - it imposes the same level of discard for all flows. If the audit function detects non-compliance, it will drop packets from the non-complying flow(s), which of course reduces their rate. But this is to make the outgoing congestion *information* compliant, not because it has a particular view of how each flow should make their rate respond to congestion. This complies with the requirement in conex-abstract-mech: "Transport Oblivious: Audit MUST NOT be designed around one particular rate response, such as any particular TCP congestion control algorithm or one particular resource sharing regime such as TCP-friendliness [RFC3448]. An important goal is to give ingress networks the freedom to unilaterally allow different rate responses to congestion and different resource sharing regimes [Evol_cc], without having to coordinate with downstream networks; " [BTW, when I talk about the audit function, you keep switching to the policing function. Are you sure you are using the terms as defined in conex-abstract-mech?] > > > >ConEx audit checks on a per-flow basis that signalling of expected > >congestion is no less than actual congestion. This ensures the > >integrity of the ConEx information so that it can be used for traffic > >management in bulk, e.g at domain boundaries or at the boundary with > >the consumer at the sender end. > > > >(Of course, a network operator could still choose to do per-flow > >traffic management. However if their goal is to control traffic cost > >or to control one consumer's impact on others it is sufficient for a > >network operator to use ConEx information to manage traffic behaviour > >in bulk, not per flow.) > >Georgios: Do you mean that Conex will not require the use of a per-flow >policer? Very definitely yes. That is the main goal of the whole exercise. If you missed this point, I can understand why you wrote your draft. This is why I have been arguing that conex-concepts-uses needs to say what we are NOT trying to do. Footnotes _________ {Note 1}: If only the downstream network uses ConEx, then it may not be able to get the upstream network to agree to a traffic contract that includes ConEx information. But it would still want to deploy a ConEx policer at the border. This policer could choose not to use flow-state. However, then one upstream sender could cause the policer to hurt traffic from other upstream senders. Two possibilities: i) The downstream network might say to the upstream network "Tough, if you want to protect your users from DoS attackers on your network, police them using ConEx info." ii) However, more likely, the downstream network will want a congestion policer that does some sampling to detect ConEx flows that are causing excessive congestion, and it will separate them out to be the ones that discards are focused on whenever the whole bulk of traffic is out of contract. If a DoS attacker was spoofing different source addresses, this policer could do full per-flow processing (like DoS protection does today). Then it would be easy to discard any packets that say they are ConEx enabled but belong to a flow that has not started with sufficient positive ConEx markings (green or black). For instance ConEx-enabled SYNs without a 'green' marking could automatically be discarded. But if I was the downstream network, I would charge the upstream network for sorting out their DoS problems for them (that would pay for the equipment I would buy to do all this flow-processing). If they don't want to pay, they always have option (i) available to them. Option (i) is the goal, because once the upstream network deploys a ConEx policer at the ingress from the sender's network, it doesn't need to do flow processing. If any DoS sources within the sender's network affect other traffic from that same sender, the problem is confined to the sending network hurting itself. {Note 2}: The original SIGCOMM paper on re-feedback may have caused your confusion. Because the prevailing religion of most SIGCOMM reviewers at the time assumed the goal was to police individual TCP behaviour, to get the paper accepted we had to show that re-feedback could do this. But then we showed you didn't need to in a following section (a later paper "Policing Freedom..." focused on bulk policing). If the source of confusion was one of the current ConEx w-g documents, not this SIGCOMM paper, please say. We will need to fix that. Cheers Bob >Best regards, >Georgios > > > > > > > > >Bob > > > >At 07:39 01/07/2011, Georgios Karagiannis wrote: > >>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 > >>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] > >> >> 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 > >> >> > >> >> 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 > >> >> > >> >> _______________________________________________ > >> >> conex mailing list > >> >> conex@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/conex > >> >> > > > >________________________________________________________________ > >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_61457000==.ALT Content-Type: text/html; charset="us-ascii" Georgios,

[Mike, I've also directed this response to you - please see "{Note 1}" inline that answers a question I recall you asked months ago. I don't think I ever answered it - probably got distracted by something.]

At 19:45 04/07/2011, Georgios Karagiannis wrote:
Hi Bob,

Please see in line!

On 7/4/2011, "Bob Briscoe" <bob.briscoe@bt.com> wrote:

>Georgios,
>
>Yes, it's true that domains wouldn't act on unverifiable information.
>
>ConEx is designed to solve that problem; to provide downstream
>congestion measurements at domain boundaries that are verifiable and
>that can be used in bulk without per-flow processing or state.
>
>To achieve that, unfortunately we still need the ConEx audit
>function, which no-one has yet been able to do without per-flow
>state.

Georgios: Is it not necessay to use a policer?

Three points:
a) I assume you are using the terms 'policer' and 'audit function' as in conex-abstract-mech?
b) It isn't necessary to use a policer between networks. Indeed, I would not recommend a policer between two networks that both use ConEx info to protect their respective networks.{Note 1} A traffic contract with penalties for sending too much congestion will be sufficient.
c) A policer does not need to use flow-state. It can act on the bulk of traffic passing from the consumer to their ingress network.

> However, very importantly:
>- per-flow ConEx audit is only necessary at the last egress edge of
>the internetwork. Every flow does not need to be checked at borders.

Georgios: Okay, but I assume that whenever the congestion rate needs to
be measured, then a per-flow state is needed.

Not at all. Just like bit-rate, congestion rate is a metric that can measure any granularity: flows, aggregates or all the traffic on a link. ConEx markings are designed to correctly characterise the amount of traffic causing congestion at any granularity - without having to measure at finer granularities and add them up.

For instance, a "congestion token bucket policer" measures the congestion rate and it can be applied at the granularity of a link without looking at flows. Just like a normal token bucket can be applied without looking at flows. Whenever a ConEx marked packet arrives, tokens are removed from this bucket, without caring about flows.

Please check the following
draft that somehow tries to describe this issue:
http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt

Ah! Your draft *assumes* that the congestion rate is being measured per flow, then essentially it says it would be complex to measure the congestion rate per flow.

I think you've seriously misunderstood. Although ConEx *could* be used to make sure individual flows conform to the TCP behaviour, that is neither necessary nor the goal. In fact it is a non-goal.{Note 2}

The argument is that it would actually be very wrong to try to get flows to conform to the TCP behaviour. Embedding such policers in the network would prevent future evolution of better congestion controls.

I will add this to the list of misconceptions in conex-uses.


>- ConEx audit does not aim to control the rate behaviour of flows, it
>is solely a per-flow information check. This means no-one needs to
>define how individual flows should behave, which is an important achievement.

Georgios: okay, but I assume that when a policer is used, then the
control of the rate behaviour will be affected!

Of course. But if it is a bulk policer, it only limits the bulk rate - it imposes the same level of discard for all flows.

If the audit function detects non-compliance, it will drop packets from the non-complying flow(s), which of course reduces their rate. But this is to make the outgoing congestion *information* compliant, not because it has a particular view of how each flow should make their rate respond to congestion. This complies with the requirement in conex-abstract-mech:

"Transport Oblivious:
Audit MUST NOT be designed around one particular rate response, such as any particular TCP congestion control algorithm or one particular resource sharing regime such as TCP-friendliness [RFC3448]. An important goal is to give ingress networks the freedom to unilaterally allow different rate responses to congestion and different resource sharing regimes [Evol_cc], without having to coordinate with downstream networks; "

[BTW, when I talk about the audit function, you keep switching to the policing function. Are you sure you are using the terms as defined in conex-abstract-mech?]

>
>ConEx audit checks on a per-flow basis that signalling of expected
>congestion is no less than actual congestion. This ensures the
>integrity of the ConEx information so that it can be used for traffic
>management in bulk, e.g at domain boundaries or at the boundary with
>the consumer at the sender end.
>
>(Of course, a network operator could still choose to do per-flow
>traffic management. However if their goal is to control traffic cost
>or to control one consumer's impact on others it is sufficient for a
>network operator to use ConEx information to manage traffic behaviour
>in bulk, not per flow.)

Georgios: Do you mean that Conex will not require the use of a per-flow
policer?

Very definitely yes. That is the main goal of the whole exercise. If you missed this point, I can understand why you wrote your draft. This is why I have been arguing that conex-concepts-uses needs to say what we are NOT trying to do.

Footnotes
_________
{Note 1}: If only the downstream network uses ConEx, then it may not be able to get the upstream network to agree to a traffic contract that includes ConEx information. But it would still want to deploy a ConEx policer at the border.

This policer could choose not to use flow-state. However, then one upstream sender could cause the policer to hurt traffic from other upstream senders. Two possibilities:
i) The downstream network might say to the upstream network "Tough, if you want to protect your users from DoS attackers on your network, police them using ConEx info."
ii) However, more likely, the downstream network will want a congestion policer that does some sampling to detect ConEx flows that are causing excessive congestion, and it will separate them out to be the ones that discards are focused on whenever the whole bulk of traffic is out of contract.

If a DoS attacker was spoofing different source addresses, this policer could do full per-flow processing (like DoS protection does today). Then it would be easy to discard any packets that say they are ConEx enabled but belong to a flow that has not started with sufficient positive ConEx markings (green or black). For instance ConEx-enabled SYNs without a 'green' marking could automatically be discarded.

But if I was the downstream network, I would charge the upstream network for sorting out their DoS problems for them (that would pay for the equipment I would buy to do all this flow-processing). If they don't want to pay, they always have option (i) available to them.

Option (i) is the goal, because once the upstream network deploys a ConEx policer at the ingress from the sender's network, it doesn't need to do flow processing. If any DoS sources within the sender's network affect other traffic from that same sender, the problem is confined to the sending network hurting itself.

{Note 2}: The original SIGCOMM paper on re-feedback may have caused your confusion. Because the prevailing religion of most SIGCOMM reviewers at the time assumed the goal was to police individual TCP behaviour, to get the paper accepted we had to show that re-feedback could do this. But then we showed you didn't need to in a following section (a later paper "Policing Freedom..." focused on bulk policing).

If the source of confusion was one of the current ConEx w-g documents, not this SIGCOMM paper, please say. We will need to fix that.

Cheers



Bob

Best regards,
Georgios

>
>
>
>Bob
>
>At 07:39 01/07/2011, Georgios Karagiannis wrote:
>>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
>>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" <Michael.Scharf@alcatel-lucent.com>
>>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]
>> >> 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
>> >>
>> >> 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" <bob.briscoe@bt.com> 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
>> >>
>> >> _______________________________________________
>> >> conex mailing list
>> >> conex@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/conex
>> >>
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_61457000==.ALT-- From john@jlc.net Tue Jul 5 08:49: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 5F49911E811B for ; Tue, 5 Jul 2011 08:49:10 -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=[AWL=0.000, 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 z87K5Ijdi-w2 for ; Tue, 5 Jul 2011 08:49:09 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7C11E8158 for ; Tue, 5 Jul 2011 08:48:59 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4B17C33C23; Tue, 5 Jul 2011 11:48:58 -0400 (EDT) Date: Tue, 5 Jul 2011 11:48:58 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110705154858.GO52796@verdi> References: <201107041502.p64F2cdw008542@bagheera.jungle.bt.co.uk> <201107050911.p659BXY8013753@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107050911.p659BXY8013753@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" Subject: [conex] ConEx Policing 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, 05 Jul 2011 15:49:10 -0000 Bob has done a rather good introduction to policing here. I can only add the view of an operator: that I would leave all policing off by default. Turning it on would, in all likelihood, be at the request of a _customer_ who was experiencing what amounts to a mini-DoS -- where the link he's willing to pay for is getting overloaded. (Alas, in the US it's far cheaper to do policing than upgrade a link.) I might also turn it on for what amounts to "transit" -- where traffic coming from a peer exceeds my (non-contractual) allowance for _volume_ of congestion-expected, and I want to ensure that I don't exceed my (contractual) allowance going out to a different peer. Generally, though, it would be easier to police the outgoing traffic to peers where I had a contractual allowance. Only in the case where I'm doing it for a customer would I care to try to match policing to individual flows. (And only on the outgoing link to a customer would I consider that practical -- but even if it were practical I wouldn't want to be bothered.) I believe this issue deserves to be in a separate draft. It's inherently confusing, and IMHO it's far better for an introductory RFC to mention it _only_ by reference. Bob Briscoe wrote: > At 19:45 04/07/2011, Georgios Karagiannis wrote: >> >> Is it not necessay to use a policer? > > Three points: > > a) I assume you are using the terms 'policer' and 'audit function' as > in conex-abstract-mech? > > b) It isn't necessary to use a policer between networks. Indeed, I > would not recommend a policer between two networks that both use > ConEx info to protect their respective networks.{Note 1} A traffic > contract with penalties for sending too much congestion will be > sufficient. This gives the sending network an incentive to do policing, which hopefully wouldn't need to drop/disincent anything most of the time. > c) A policer does not need to use flow-state. It can act on the bulk > of traffic passing from the consumer to their ingress network. > >> Okay, but I assume that whenever the congestion rate needs to be >> measured, then a per-flow state is needed. As an operator, I see no reason to measure "congestion rate" at all. It does nothing to help me. Congestion-Expected _volume_ is the metric I'm interested in. > Not at all. Just like bit-rate, congestion rate is a metric that can > measure any granularity: flows, aggregates or all the traffic on a > link. ConEx markings are designed to correctly characterise the > amount of traffic causing congestion at any granularity - without > having to measure at finer granularities and add them up. > > For instance, a "congestion token bucket policer" measures the > congestion rate and it can be applied at the granularity of a link > without looking at flows. Just like a normal token bucket can be > applied without looking at flows. Whenever a ConEx marked packet > arrives, tokens are removed from this bucket, without caring about flows. > >> Please check the following draft that somehow tries to describe this >> issue: >> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt > > I think you've seriously misunderstood. Although ConEx *could* be > used to make sure individual flows conform to the TCP behaviour, that > is neither necessary nor the goal. In fact it is a non-goal.{Note 2} (It might be helpful to list such "non-goals" in an introductory RFC...) > The argument is that it would actually be very wrong to try to get > flows to conform to the TCP behaviour. Embedding such policers in the > network would prevent future evolution of better congestion controls. > > I will add this to the list of misconceptions in conex-uses. I continue to recommend against any such list in Concepts-Uses. Listing "non-goals" is far better. "Misconceptions" tends to pick a fight with anyone who believes the conception. >> okay, but I assume that when a policer is used, then the control of >> the rate behaviour will be affected! > > Of course. But if it is a bulk policer, it only limits the bulk rate > - it imposes the same level of discard for all flows. Bulk Policer is the easiest to implement, and it _is_ sufficient for many needs. > If the audit function detects non-compliance, it will drop packets > from the non-complying flow(s), which of course reduces their rate. > But this is to make the outgoing congestion *information* compliant, > not because it has a particular view of how each flow should make > their rate respond to congestion. This complies with the requirement > in conex-abstract-mech: Possible confusion: to me "audit function" implies _only_ measuring. Dropping packets belongs to some other function. > "Transport Oblivious: > Audit MUST NOT be designed around one particular rate response, such > as any particular TCP congestion control algorithm or one particular > resource sharing regime such as TCP-friendliness > [BTW, when I talk about the audit function, you keep switching to the > policing function. Are you sure you are using the terms as defined in > conex-abstract-mech?] In fairness, Bob, there _isn't_ a definition of "audit function" in Abstract-Mech. And there are enough occurances of "sanction" in Section 4.3 to make it _very_ easy for Georgios to believe "audit funciton" includes policing. But, as I said, I'd really prefer not to get bogged down in minutiae of Abstract-Mech. (And we _definitely_ shouldn't be trying to solve ambiguity of Abstract-Mech in Concepts-Uses!) > ... > Footnotes > _________ > {Note 1}: If only the downstream network uses ConEx, then it may not > be able to get the upstream network to agree to a traffic contract > that includes ConEx information. But it would still want to deploy a > ConEx policer at the border. "might want", please. > This policer could choose not to use flow-state. However, then one > upstream sender could cause the policer to hurt traffic from other > upstream senders. Two possibilities: > > i) The downstream network might say to the upstream network "Tough, > if you want to protect your users from DoS attackers on your network, > police them using ConEx info." > > ii) However, more likely, the downstream network will want a > congestion policer that does some sampling to detect ConEx flows > that are causing excessive congestion, and it will separate them > out to be the ones that discards are focused on whenever the > whole bulk of traffic is out of contract. Per-flow state at a major peering point would have to be limited to a "reasonable" number of flows... > If a DoS attacker was spoofing different source addresses, this > policer could do full per-flow processing (like DoS protection does > today). Then it would be easy to discard any packets that say they > are ConEx enabled but belong to a flow that has not started with > sufficient positive ConEx markings (green or black). For instance > ConEx-enabled SYNs without a 'green' marking could automatically be > discarded. (Technical issue here, Bob: I'll let you work it out...) > But if I was the downstream network, I would charge the upstream > network for sorting out their DoS problems for them (that would pay > for the equipment I would buy to do all this flow-processing). If > they don't want to pay, they always have option (i) available to them. Agreed. > Option (i) is the goal, because once the upstream network deploys a > ConEx policer at the ingress from the sender's network, it doesn't > need to do flow processing. If any DoS sources within the sender's > network affect other traffic from that same sender, the problem is > confined to the sending network hurting itself. Agreed (though in DDos, an attacker might find enough botted computers to cause trouble without any of them exceeding their allowance.) > If the source of confusion was one of the current ConEx w-g > documents, not this SIGCOMM paper, please say. We will need to fix > that. I do recommend some attention to Section 4.3 of Abstract-Mech, Bob. -- John Leslie From bob.briscoe@bt.com Tue Jul 5 13:34: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 9578921F88D2 for ; Tue, 5 Jul 2011 13:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1D7AF5bPdE1 for ; Tue, 5 Jul 2011 13:34: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 2B30321F8839 for ; Tue, 5 Jul 2011 13:34:57 -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); Tue, 5 Jul 2011 21:34:55 +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, 5 Jul 2011 21:34:55 +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 1309898094135; Tue, 5 Jul 2011 21:34:54 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.208.56]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p65KYoH0016661; Tue, 5 Jul 2011 21:34:51 +0100 Message-Id: <201107052034.p65KYoH0016661@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Jul 2011 21:34:48 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20110705154858.GO52796@verdi> References: <201107041502.p64F2cdw008542@bagheera.jungle.bt.co.uk> <201107050911.p659BXY8013753@bagheera.jungle.bt.co.uk> <20110705154858.GO52796@verdi> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_102452418==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 05 Jul 2011 20:34:55.0369 (UTC) FILETIME=[FFE88F90:01CC3B52] Cc: "conex@ietf.org" Subject: Re: [conex] ConEx Policing 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, 05 Jul 2011 20:34:59 -0000 --=====================_102452418==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed John, At 16:48 05/07/2011, John Leslie wrote: > Bob has done a rather good introduction to policing here. I can >only add the view of an operator: that I would leave all policing off >by default. > > Turning it on would, in all likelihood, be at the request of a >_customer_ who was experiencing what amounts to a mini-DoS -- where >the link he's willing to pay for is getting overloaded. (Alas, in >the US it's far cheaper to do policing than upgrade a link.) > > I might also turn it on for what amounts to "transit" -- where >traffic coming from a peer exceeds my (non-contractual) allowance >for _volume_ of congestion-expected, and I want to ensure that I >don't exceed my (contractual) allowance going out to a different >peer. Generally, though, it would be easier to police the outgoing >traffic to peers where I had a contractual allowance. > > Only in the case where I'm doing it for a customer would I care >to try to match policing to individual flows. (And only on the >outgoing link to a customer would I consider that practical -- but >even if it were practical I wouldn't want to be bothered.) > > I believe this issue deserves to be in a separate draft. It's >inherently confusing, and IMHO it's far better for an introductory >RFC to mention it _only_ by reference. Agree. We (rightly) have nothing specific on policing in conex-concepts-uses. We have some overview in conex-abstract-mech. A good scholarly paper on congestion-policing from someone would be useful to refer to. Especially if they were willing to donate the text to the IETF, for the w-g to knock into an RFC. I'm working on such a thing, but only in my spare time (huh!). >Bob Briscoe wrote: > > At 19:45 04/07/2011, Georgios Karagiannis wrote: > >> > >> Is it not necessay to use a policer? > > > > Three points: > > > > a) I assume you are using the terms 'policer' and 'audit function' as > > in conex-abstract-mech? > > > > b) It isn't necessary to use a policer between networks. Indeed, I > > would not recommend a policer between two networks that both use > > ConEx info to protect their respective networks.{Note 1} A traffic > > contract with penalties for sending too much congestion will be > > sufficient. > > This gives the sending network an incentive to do policing, which >hopefully wouldn't need to drop/disincent anything most of the time. > > > c) A policer does not need to use flow-state. It can act on the bulk > > of traffic passing from the consumer to their ingress network. > > > >> Okay, but I assume that whenever the congestion rate needs to be > >> measured, then a per-flow state is needed. > > As an operator, I see no reason to measure "congestion rate" at >all. It does nothing to help me. Congestion-Expected _volume_ is the >metric I'm interested in. I glossed over that point. I imagine a token-bucket as the mechanism, or preferably a leaky-token-bucket. The contracted rate of the bucket can be thought of as limiting congestion-volume over a duration, so in that sense I would agree with John that the instantaneous congestion-rate at any one time would not concern an operator. However, an operator would want to limit the size of bursts of congestion-rate. That's where the leaky part of the leaky-token-bucket would come in handy. So in that sense (and only that), an operator would be interested in congestion-rate. > > Not at all. Just like bit-rate, congestion rate is a metric that can > > measure any granularity: flows, aggregates or all the traffic on a > > link. ConEx markings are designed to correctly characterise the > > amount of traffic causing congestion at any granularity - without > > having to measure at finer granularities and add them up. > > > > For instance, a "congestion token bucket policer" measures the > > congestion rate and it can be applied at the granularity of a link > > without looking at flows. Just like a normal token bucket can be > > applied without looking at flows. Whenever a ConEx marked packet > > arrives, tokens are removed from this bucket, without caring about flows. > > > >> Please check the following draft that somehow tries to describe this > >> issue: > >> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt > > > > I think you've seriously misunderstood. Although ConEx *could* be > > used to make sure individual flows conform to the TCP behaviour, that > > is neither necessary nor the goal. In fact it is a non-goal.{Note 2} > > (It might be helpful to list such "non-goals" in an introductory >RFC...) > > > The argument is that it would actually be very wrong to try to get > > flows to conform to the TCP behaviour. Embedding such policers in the > > network would prevent future evolution of better congestion controls. > > > > I will add this to the list of misconceptions in conex-uses. > > I continue to recommend against any such list in Concepts-Uses. >Listing "non-goals" is far better. "Misconceptions" tends to pick a >fight with anyone who believes the conception. OK, I see your point, but it's made without knowing the proposed text - I'll start a new thread next email. > >> okay, but I assume that when a policer is used, then the control of > >> the rate behaviour will be affected! > > > > Of course. But if it is a bulk policer, it only limits the bulk rate > > - it imposes the same level of discard for all flows. > > Bulk Policer is the easiest to implement, and it _is_ sufficient >for many needs. Indeed. Once someone is out of order, it doesn't so much matter if you punish some of their flows more than they deserve and others less. Their remedy is to get back in contract, then it won't matter. > > If the audit function detects non-compliance, it will drop packets > > from the non-complying flow(s), which of course reduces their rate. > > But this is to make the outgoing congestion *information* compliant, > > not because it has a particular view of how each flow should make > > their rate respond to congestion. This complies with the requirement > > in conex-abstract-mech: > > Possible confusion: to me "audit function" implies _only_ measuring. >Dropping packets belongs to some other function. True. I should not have said "it will drop packets". > > "Transport Oblivious: > > Audit MUST NOT be designed around one particular rate response, such > > as any particular TCP congestion control algorithm or one particular > > resource sharing regime such as TCP-friendliness > > > I'd really prefer not to get bogged down in minutiae of Abstract-Mech. > > [BTW, when I talk about the audit function, you keep switching to the > > policing function. Are you sure you are using the terms as defined in > > conex-abstract-mech?] > > In fairness, Bob, there _isn't_ a definition of "audit function" in >Abstract-Mech. And there are enough occurances of "sanction" in Section >4.3 to make it _very_ easy for Georgios to believe "audit funciton" >includes policing. > > But, as I said, I'd really prefer not to get bogged down in minutiae >of Abstract-Mech. (And we _definitely_ shouldn't be trying to solve >ambiguity of Abstract-Mech in Concepts-Uses!) Indeed. I don't think Georgios is particularly focusing on concepts-uses. He seems to be trying to understand ConEx from reading lots of docs (including non-w-g stuff I think). Nonetheless, under Requirements, abstract-mech does say: "The auditing mechanism must have a capability for providing sufficient disincentives against misreported congestion, such as by throttling traffic that reports less congestion than it is actually experiencing. " > > ... > > Footnotes > > _________ > > {Note 1}: If only the downstream network uses ConEx, then it may not > > be able to get the upstream network to agree to a traffic contract > > that includes ConEx information. But it would still want to deploy a > > ConEx policer at the border. > > "might want", please. Yup > > This policer could choose not to use flow-state. However, then one > > upstream sender could cause the policer to hurt traffic from other > > upstream senders. Two possibilities: > > > > i) The downstream network might say to the upstream network "Tough, > > if you want to protect your users from DoS attackers on your network, > > police them using ConEx info." > > > > ii) However, more likely, the downstream network will want a > > congestion policer that does some sampling to detect ConEx flows > > that are causing excessive congestion, and it will separate them > > out to be the ones that discards are focused on whenever the > > whole bulk of traffic is out of contract. > > Per-flow state at a major peering point would have to be limited >to a "reasonable" number of flows... Yup. Hence sampling. > > If a DoS attacker was spoofing different source addresses, this > > policer could do full per-flow processing (like DoS protection does > > today). Then it would be easy to discard any packets that say they > > are ConEx enabled but belong to a flow that has not started with > > sufficient positive ConEx markings (green or black). For instance > > ConEx-enabled SYNs without a 'green' marking could automatically be > > discarded. > > (Technical issue here, Bob: I'll let you work it out...) > > > But if I was the downstream network, I would charge the upstream > > network for sorting out their DoS problems for them (that would pay > > for the equipment I would buy to do all this flow-processing). If > > they don't want to pay, they always have option (i) available to them. > > Agreed. > > > Option (i) is the goal, because once the upstream network deploys a > > ConEx policer at the ingress from the sender's network, it doesn't > > need to do flow processing. If any DoS sources within the sender's > > network affect other traffic from that same sender, the problem is > > confined to the sending network hurting itself. > > Agreed (though in DDos, an attacker might find enough botted >computers to cause trouble without any of them exceeding their allowance.) All ConEx can claim to do is raise the bar - by n times to be precise, where n = 1/p* and p* is the typical average congestion level the operator designs for over the peak period (without DDoS). So if p* = 0.1%, then n = 1000. That means ConEx would require botnets to conscript 1000x more bots for the same effect. n would be less if the policers were at borders remote from the bots, sized for many users behind whole networks. That's harder to work out (meaning I haven't tried). > > If the source of confusion was one of the current ConEx w-g > > documents, not this SIGCOMM paper, please say. We will need to fix > > that. > > I do recommend some attention to Section 4.3 of Abstract-Mech, Bob. Specifically? I do notice that it doesn't actually say what Audit is. It goes straight into the middle of a conversation about implementation. We (matt & I) have an -02 nearly ready. But I'm focusing on concepts-uses at the mo. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_102452418==.ALT Content-Type: text/html; charset="us-ascii" John,

At 16:48 05/07/2011, John Leslie wrote:

   Bob has done a rather good introduction to policing here. I can
only add the view of an operator: that I would leave all policing off
by default.

   Turning it on would, in all likelihood, be at the request of a
_customer_ who was experiencing what amounts to a mini-DoS -- where
the link he's willing to pay for is getting overloaded. (Alas, in
the US it's far cheaper to do policing than upgrade a link.)

   I might also turn it on for what amounts to "transit" -- where
traffic coming from a peer exceeds my (non-contractual) allowance
for _volume_ of congestion-expected, and I want to ensure that I
don't exceed my (contractual) allowance going out to a different
peer. Generally, though, it would be easier to police the outgoing
traffic to peers where I had a contractual allowance.

   Only in the case where I'm doing it for a customer would I care
to try to match policing to individual flows. (And only on the
outgoing link to a customer would I consider that practical -- but
even if it were practical I wouldn't want to be bothered.)

   I believe this issue deserves to be in a separate draft. It's
inherently confusing, and IMHO it's far better for an introductory
RFC to mention it _only_ by reference.

Agree.

We (rightly) have nothing specific on policing in conex-concepts-uses.
We have some overview in conex-abstract-mech.

A good scholarly paper on congestion-policing from someone would be useful to refer to. Especially if they were willing to donate the text to the IETF, for the w-g to knock into an RFC. I'm working on such a thing, but only in my spare time (huh!).


Bob Briscoe <bob.briscoe@bt.com> wrote:
> At 19:45 04/07/2011, Georgios Karagiannis wrote:
>>
>> Is it not necessay to use a policer?
>
> Three points:
>
> a) I assume you are using the terms 'policer' and 'audit function' as
> in conex-abstract-mech?
>
> b) It isn't necessary to use a policer between networks. Indeed, I
> would not recommend a policer between two networks that both use
> ConEx info to protect their respective networks.{Note 1} A traffic
> contract with penalties for sending too much congestion will be
> sufficient.

   This gives the sending network an incentive to do policing, which
hopefully wouldn't need to drop/disincent anything most of the time.

> c) A policer does not need to use flow-state. It can act on the bulk
> of traffic passing from the consumer to their ingress network.
>
>> Okay, but I assume that whenever the congestion rate needs to be
>> measured, then a per-flow state is needed.

   As an operator, I see no reason to measure "congestion rate" at
all. It does nothing to help me. Congestion-Expected _volume_ is the
metric I'm interested in.

I glossed over that point. I imagine a token-bucket as the mechanism, or preferably a leaky-token-bucket. The contracted rate of the bucket can be thought of as limiting congestion-volume over a duration, so in that sense I would agree with John that the instantaneous congestion-rate at any one time would not concern an operator.

However, an operator would want to limit the size of bursts of congestion-rate. That's where the leaky part of the leaky-token-bucket would come in handy. So in that sense (and only that), an operator would be interested in congestion-rate.


> Not at all. Just like bit-rate, congestion rate is a metric that can
> measure any granularity: flows, aggregates or all the traffic on a
> link. ConEx markings are designed to correctly characterise the
> amount of traffic causing congestion at any granularity - without
> having to measure at finer granularities and add them up.
>
> For instance, a "congestion token bucket policer" measures the
> congestion rate and it can be applied at the granularity of a link
> without looking at flows. Just like a normal token bucket can be
> applied without looking at flows. Whenever a ConEx marked packet
> arrives, tokens are removed from this bucket, without caring about flows.
>
>> Please check the following draft that somehow tries to describe this
>> issue:
>> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt
>
> I think you've seriously misunderstood. Although ConEx *could* be
> used to make sure individual flows conform to the TCP behaviour, that
> is neither necessary nor the goal. In fact it is a non-goal.{Note 2}

   (It might be helpful to list such "non-goals" in an introductory
RFC...)

> The argument is that it would actually be very wrong to try to get
> flows to conform to the TCP behaviour. Embedding such policers in the
> network would prevent future evolution of better congestion controls.
>
> I will add this to the list of misconceptions in conex-uses.

   I continue to recommend against any such list in Concepts-Uses.
Listing "non-goals" is far better. "Misconceptions" tends to pick a
fight with anyone who believes the conception.

OK, I see your point, but it's made without knowing the proposed text - I'll start a new thread next email.


>> okay, but I assume that when a policer is used, then the control of
>> the rate behaviour will be affected!
>
> Of course. But if it is a bulk policer, it only limits the bulk rate
> - it imposes the same level of discard for all flows.

   Bulk Policer is the easiest to implement, and it _is_ sufficient
for many needs.

Indeed. Once someone is out of order, it doesn't so much matter if you punish some of their flows more than they deserve and others less. Their remedy is to get back in contract, then it won't matter.


> If the audit function detects non-compliance, it will drop packets
> from the non-complying flow(s), which of course reduces their rate.
> But this is to make the outgoing congestion *information* compliant,
> not because it has a particular view of how each flow should make
> their rate respond to congestion. This complies with the requirement
> in conex-abstract-mech:

   Possible confusion: to me "audit function" implies _only_ measuring.
Dropping packets belongs to some other function.

True. I should not have said "it will drop packets".


> "Transport Oblivious:
> Audit MUST NOT be designed around one particular rate response, such
> as any particular TCP congestion control algorithm or one particular
> resource sharing regime such as TCP-friendliness
> <http://www.jungle.bt.co.uk/people/rbriscoe/ext/projects/conex/draft-ietf-conex-abstract-mech-01.html...
   I'd really prefer not to get bogged down in minutiae of Abstract-Mech.
> [BTW, when I talk about the audit function, you keep switching to the
> policing function. Are you sure you are using the terms as defined in
> conex-abstract-mech?]

   In fairness, Bob, there _isn't_ a definition of "audit function" in
Abstract-Mech. And there are enough occurances of "sanction" in Section
4.3 to make it _very_ easy for Georgios to believe "audit funciton"
includes policing.

   But, as I said, I'd really prefer not to get bogged down in minutiae
of Abstract-Mech. (And we _definitely_ shouldn't be trying to solve
ambiguity of Abstract-Mech in Concepts-Uses!)

Indeed.

I don't think Georgios is particularly focusing on concepts-uses. He seems to be trying to understand ConEx from reading lots of docs (including non-w-g stuff I think).

Nonetheless, under Requirements, abstract-mech does say:
"The auditing mechanism must have a capability for providing sufficient disincentives against misreported congestion, such as by throttling traffic that reports less congestion than it is actually experiencing. "


> ...
> Footnotes
> _________
> {Note 1}: If only the downstream network uses ConEx, then it may not
> be able to get the upstream network to agree to a traffic contract
> that includes ConEx information. But it would still want to deploy a
> ConEx policer at the border.

   "might want", please.

Yup


> This policer could choose not to use flow-state. However, then one
> upstream sender could cause the policer to hurt traffic from other
> upstream senders. Two possibilities:
>
> i) The downstream network might say to the upstream network "Tough,
>    if you want to protect your users from DoS attackers on your network,
>    police them using ConEx info."
>
> ii) However, more likely, the downstream network will want a
>     congestion policer that does some sampling to detect ConEx flows
>     that are causing excessive congestion, and it will separate them
>     out to be the ones that discards are focused on whenever the
>     whole bulk of traffic is out of contract.

   Per-flow state at a major peering point would have to be limited
to a "reasonable" number of flows...

Yup. Hence sampling.


> If a DoS attacker was spoofing different source addresses, this
> policer could do full per-flow processing (like DoS protection does
> today). Then it would be easy to discard any packets that say they
> are ConEx enabled but belong to a flow that has not started with
> sufficient positive ConEx markings (green or black). For instance
> ConEx-enabled SYNs without a 'green' marking could automatically be
> discarded.

   (Technical issue here, Bob: I'll let you work it out...)

> But if I was the downstream network, I would charge the upstream
> network for sorting out their DoS problems for them (that would pay
> for the equipment I would buy to do all this flow-processing). If
> they don't want to pay, they always have option (i) available to them.

   Agreed.

> Option (i) is the goal, because once the upstream network deploys a
> ConEx policer at the ingress from the sender's network, it doesn't
> need to do flow processing. If any DoS sources within the sender's
> network affect other traffic from that same sender, the problem is
> confined to the sending network hurting itself.

   Agreed (though in DDos, an attacker might find enough botted
computers to cause trouble without any of them exceeding their allowance.)

All ConEx can claim to do is raise the bar - by n times to be precise, where n = 1/p* and p* is the typical average congestion level the operator designs for over the peak period (without DDoS). So if p* = 0.1%, then n = 1000. That means ConEx would require botnets to conscript 1000x more bots for the same effect.

n would be less if the policers were at borders remote from the bots, sized for many users behind whole networks. That's harder to work out (meaning I haven't tried).


> If the source of confusion was one of the current ConEx w-g
> documents, not this SIGCOMM paper, please say. We will need to fix
> that.

   I do recommend some attention to Section 4.3 of Abstract-Mech, Bob.

Specifically?

I do notice that it doesn't actually say what Audit is. It goes straight into the middle of a conversation about implementation.

We (matt & I) have an -02 nearly ready. But I'm focusing on concepts-uses at the mo.


Bob


--
John Leslie <john@jlc.net>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_102452418==.ALT-- From karagian@cs.utwente.nl Tue Jul 5 22:18: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 ECADF21F8596 for ; Tue, 5 Jul 2011 22:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.543 X-Spam-Level: X-Spam-Status: No, score=0.543 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 8Srr+gpq9OXt for ; Tue, 5 Jul 2011 22:18:26 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1DA21F8591 for ; Tue, 5 Jul 2011 22:18:25 -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 p665GiHO011727; Wed, 6 Jul 2011 07:16:44 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 05:18:23 +0000 To: "Bob Briscoe" , "Mikael Abrahamsson" Date: Wed, 06 Jul 2011 05:18:21 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107050911.p659BXY8013753@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]); Wed, 06 Jul 2011 07:16:56 +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: Wed, 06 Jul 2011 05:18:28 -0000 Hi Bob, Thank you very much for the detailed explanation. I will try to explain my thoughts on why I think that a Conex congestion policer needs per flow state. The main solution proposed in [draft-ietf-conex-abstract-mech-01] to audit Conex Signals against actual losses (i.e., the measured congestion rate) an auditor could use one of the following tecniques "The auditor could monitor TCP flows or aggregates of flows, only holding state on a flow if it first sends a Credit or a Re-Echo-Loss marking. The auditor could detect retransmissions by monitoring sequence numbers. It would assure that (volume of retransmitted data) <=3D (volume of data marked Re-Echo-Loss). Traffic would only be auditable in this way if it conformed to the standard TCP protocol and the IP payload was not encrypted (e.g. with IPsec). ", from [draft-ietf-conex-abstract-mech-01]. In other words, an audit device needs to keep per flow (individual or aggregated) state after it receives a credit or Re-echo-Loss marking in order to measure the per flow congestion rate. In addition to this the audit device must be able to read the TCP header in order to observe the TCP header numbers. This is complex to be implemented and it is not always possible, e.g., when the IP payload is encrypted (e.g. with IPsec). In this way, the audit device is also able to take into consideration also the number of ECN CE marked packets that were dropped by nodes located upstream. Now regarding the Conex congestion policer, [draft-ietf-conex-abstract-mech-01] specifies: "A congestion policer can be implemented in a very similar way to a bit-rate policer, but its effect can be focused solely on traffic causing congestion downstream, which ConEx signals make visible. Without ConEx signals, the only way to mitigate congestion is to blindly limit traffic bit-rate, on the assumption that high bit-rate is more likely to cause congestion. A congestion policer monitors all ConEx traffic entering a network, or some identifiable subset. Using ConEx signals, it measures the amount of congestion that this traffic is contributing to somewhere downstream. If this exceeds a policy-configured 'congestion-bit-rate' the congestion policer will limit all the monitored ConEx traffic.", from from [draft-ietf-conex-abstract-mech-01]. My concern is related to the fact that the conex congestion plolicer will use ConEx signals, as a prediction of the amount of congestion that this traffic is contributing to somewhere downstream, and then police traffic. Note that policing traffic might severely affect the rate behaviour of traffic. What I am actually saying is that in the downstream path from a sender towards the Conex congestion policer data packets will be dropped and lost. These lost packets contribute to the amount of congestion that this traffic is contributing to somewhere downstream, but they are not represented by the received Conex Signals. Thus the Conex Policer will police traffic based on a somehow inaccurate prediction of the amount of congestion that this traffic is contributing to somewhere downstream. In http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt it is explained that this inaccuracy could be solved by using the same method as the one applied in audit devices, i.e., using per flow state and measuring the rate of lost packets associated with a certain flow. In this way the Conex congestion policer can use the information provided by the Conex Signals and the rate of lost packets to accurately predict the amount of congestion that this traffic is contributing to somewhere downstream So the open issues associated with these concerns are: What is the accuracy of the Conex Signals on representing the amount of congestion that traffic is contributing to somewhere downstream? How the location of the Congestion Policer and Audit devices influence the accuracy of the Conex Signals? It will be great if these open issues could be clarified in both drafts (use cases and [draft-ietf-conex-abstract-mech-01]) Best regards, Georgios On 7/5/2011, "Bob Briscoe" wrote: >Georgios, > >[Mike, I've also directed this response to you - please see "{Note >1}" inline that answers a question I recall you asked months ago. I >don't think I ever answered it - probably got distracted by something.] > >At 19:45 04/07/2011, Georgios Karagiannis wrote: >>Hi Bob, >> >>Please see in line! >> >>On 7/4/2011, "Bob Briscoe" wrote: >> >> >Georgios, >> > >> >Yes, it's true that domains wouldn't act on unverifiable information. >> > >> >ConEx is designed to solve that problem; to provide downstream >> >congestion measurements at domain boundaries that are verifiable and >> >that can be used in bulk without per-flow processing or state. >> > >> >To achieve that, unfortunately we still need the ConEx audit >> >function, which no-one has yet been able to do without per-flow >> >state. >> >>Georgios: Is it not necessay to use a policer? > >Three points: >a) I assume you are using the terms 'policer' and 'audit function' as >in conex-abstract-mech? >b) It isn't necessary to use a policer between networks. Indeed, I >would not recommend a policer between two networks that both use >ConEx info to protect their respective networks.{Note 1} A traffic >contract with penalties for sending too much congestion will be sufficient. >c) A policer does not need to use flow-state. It can act on the bulk >of traffic passing from the consumer to their ingress network. > >> > However, very importantly: >> >- per-flow ConEx audit is only necessary at the last egress edge of >> >the internetwork. Every flow does not need to be checked at borders. >> >>Georgios: Okay, but I assume that whenever the congestion rate needs to >>be measured, then a per-flow state is needed. > >Not at all. Just like bit-rate, congestion rate is a metric that can >measure any granularity: flows, aggregates or all the traffic on a >link. ConEx markings are designed to correctly characterise the >amount of traffic causing congestion at any granularity - without >having to measure at finer granularities and add them up. > >For instance, a "congestion token bucket policer" measures the >congestion rate and it can be applied at the granularity of a link >without looking at flows. Just like a normal token bucket can be >applied without looking at flows. Whenever a ConEx marked packet >arrives, tokens are removed from this bucket, without caring about flows. > >>Please check the following >>draft that somehow tries to describe this issue: >>http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt > >Ah! Your draft *assumes* that the congestion rate is being measured >per flow, then essentially it says it would be complex to measure the >congestion rate per flow. > >I think you've seriously misunderstood. Although ConEx *could* be >used to make sure individual flows conform to the TCP behaviour, that >is neither necessary nor the goal. In fact it is a non-goal.{Note 2} > >The argument is that it would actually be very wrong to try to get >flows to conform to the TCP behaviour. Embedding such policers in the >network would prevent future evolution of better congestion controls. > >I will add this to the list of misconceptions in conex-uses. > > >> >- ConEx audit does not aim to control the rate behaviour of flows, it >> >is solely a per-flow information check. This means no-one needs to >> >define how individual flows should behave, which is an important >> achievement. >> >>Georgios: okay, but I assume that when a policer is used, then the >>control of the rate behaviour will be affected! > >Of course. But if it is a bulk policer, it only limits the bulk rate >- it imposes the same level of discard for all flows. > >If the audit function detects non-compliance, it will drop packets >from the non-complying flow(s), which of course reduces their rate. >But this is to make the outgoing congestion *information* compliant, >not because it has a particular view of how each flow should make >their rate respond to congestion. This complies with the requirement >in conex-abstract-mech: > >"Transport Oblivious: >Audit MUST NOT be designed around one particular rate response, such >as any particular TCP congestion control algorithm or one particular >resource sharing regime such as TCP-friendliness >[RFC3448]. >An important goal is to give ingress networks the freedom to >unilaterally allow different rate responses to congestion and >different resource sharing regimes >[Evol_cc], >without having to coordinate with downstream networks; " > >[BTW, when I talk about the audit function, you keep switching to the >policing function. Are you sure you are using the terms as defined in >conex-abstract-mech?] > >> > >> >ConEx audit checks on a per-flow basis that signalling of expected >> >congestion is no less than actual congestion. This ensures the >> >integrity of the ConEx information so that it can be used for traffic >> >management in bulk, e.g at domain boundaries or at the boundary with >> >the consumer at the sender end. >> > >> >(Of course, a network operator could still choose to do per-flow >> >traffic management. However if their goal is to control traffic cost >> >or to control one consumer's impact on others it is sufficient for a >> >network operator to use ConEx information to manage traffic behaviour >> >in bulk, not per flow.) >> >>Georgios: Do you mean that Conex will not require the use of a per-flow >>policer? > >Very definitely yes. That is the main goal of the whole exercise. If >you missed this point, I can understand why you wrote your draft. >This is why I have been arguing that conex-concepts-uses needs to say >what we are NOT trying to do. > >Footnotes >_________ >{Note 1}: If only the downstream network uses ConEx, then it may not >be able to get the upstream network to agree to a traffic contract >that includes ConEx information. But it would still want to deploy a >ConEx policer at the border. > >This policer could choose not to use flow-state. However, then one >upstream sender could cause the policer to hurt traffic from other >upstream senders. Two possibilities: >i) The downstream network might say to the upstream network "Tough, >if you want to protect your users from DoS attackers on your network, >police them using ConEx info." >ii) However, more likely, the downstream network will want a >congestion policer that does some sampling to detect ConEx flows that >are causing excessive congestion, and it will separate them out to be >the ones that discards are focused on whenever the whole bulk of >traffic is out of contract. > >If a DoS attacker was spoofing different source addresses, this >policer could do full per-flow processing (like DoS protection does >today). Then it would be easy to discard any packets that say they >are ConEx enabled but belong to a flow that has not started with >sufficient positive ConEx markings (green or black). For instance >ConEx-enabled SYNs without a 'green' marking could automatically be discarde= d. > >But if I was the downstream network, I would charge the upstream >network for sorting out their DoS problems for them (that would pay >for the equipment I would buy to do all this flow-processing). If >they don't want to pay, they always have option (i) available to them. > >Option (i) is the goal, because once the upstream network deploys a >ConEx policer at the ingress from the sender's network, it doesn't >need to do flow processing. If any DoS sources within the sender's >network affect other traffic from that same sender, the problem is >confined to the sending network hurting itself. > >{Note 2}: The original SIGCOMM paper on re-feedback may have caused >your confusion. Because the prevailing religion of most SIGCOMM >reviewers at the time assumed the goal was to police individual TCP >behaviour, to get the paper accepted we had to show that re-feedback >could do this. But then we showed you didn't need to in a following >section (a later paper "Policing Freedom..." focused on bulk policing). > >If the source of confusion was one of the current ConEx w-g >documents, not this SIGCOMM paper, please say. We will need to fix that. > >Cheers > > > >Bob > >>Best regards, >>Georgios >> >> > >> > >> > >> >Bob >> > >> >At 07:39 01/07/2011, Georgios Karagiannis wrote: >> >>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 >> >>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-leve= l >> >> >congestion control (XCP, RCP, etc.). >> >> > >> >> >Michael >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] >> >> >> 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 >> >> >> >> >> >> 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 netwo= rk >> >> >> > > layer. Also, because ConEx information is added >> >> >> explicitly at the IP >> >> >> > > layer, it is visible to provider and consumer alike. Therefo= re >> >> >> > > traffic contracts or acceptable use policies can be >> >> >> based on a metric >> >> >> > > that is transparent to both parties and is sufficient to mana= ge >> >> >> > > traffic without extra non-transparent wriggle-room and caveat= s. >> >> >> > >> >> >> >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 i= s >> >> >> >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 logic. >> >> >> > >* Introduce one primary use and mention there are others - to kee= p >> >> >> > >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 shar= ed >> >> >> > > capacity with packets rather than circuits. Network operator= s >> >> >> > > 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, mos= t >> >> >> > > 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 pa= th >> >> >> > > (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 other= s. >> >> >> > > >> >> >> > > 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 traff= ic >> >> >> > > 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 netwo= rk >> >> >> > > layer. Also, because ConEx information is added >> >> >> explicitly at the IP >> >> >> > > layer, it is visible to provider and consumer alike. Therefo= re >> >> >> > > traffic contracts or acceptable use policies can be >> >> >> based on a metric >> >> >> > > that is transparent to both parties and is sufficient to mana= ge >> >> >> > > traffic without extra non-transparent wriggle-room and caveat= s. >> >> >> > > >> >> >> > > 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 t= he >> >> >> > > 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 technologie= s. >> >> >> > > ConEx is a generative technology in this vein, with a range o= f >> >> >> > > 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 >> >> >> >> >> >> _______________________________________________ >> >> >> conex mailing list >> >> >> conex@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/conex >> >> >> >> > >> >________________________________________________________________ >> >Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ) From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jul 6 01:22: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 61AC221F86F7 for ; Wed, 6 Jul 2011 01:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 8FweEFl5182S for ; Wed, 6 Jul 2011 01:22:39 -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 9736421F853D for ; Wed, 6 Jul 2011 01:22:38 -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 6D19D633B1; Wed, 6 Jul 2011 10:22:36 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5E5AF59A8A; Wed, 6 Jul 2011 10:22:36 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: "conex@ietf.org" Date: Wed, 6 Jul 2011 10:22:35 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_LtBFOgXDuyeOOHv" Message-Id: <201107061022.35695.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 08:22:39 -0000 --Boundary-00=_LtBFOgXDuyeOOHv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, we submitted two new drafts regarding the needed TCP modifications for ConEx. As ConEx relies (partially) on ECN, a more accurate ECN feedback (more than max. one signal per RTT) is needed. The same information would be valuebale for other currently proposed TCP mechanisms e.g. DCTCP. This is why, we decided to split this modification into a separate and tried to specify this independent of ConEx. Thus we have two drafts now: 1. draft-kuehlewind-conex-accurate-ecn This draft currently proposes three different coding scheme to realize a more accurate ECN feedback. All approaches use the available 'classic' ECN bit space as only one mechanism (classic ECN or the new more accurate scheme) is needed at a time. The goal is to chose one of the coding options and have the other option and all discussions removed at later version of this draft. 2. draft-kuehlewind-conex-tcp-modifications This draft describes all other modifications/recommendations to use ConEx with TCP. This is the use of ECN and SACK and recommendations on the credit bit. This document contains several points which need further discussion e.g. the handling and validity of credits. Please have a look at the drafts; Feedback is very welcome! Mirja and Richard --Boundary-00=_LtBFOgXDuyeOOHv Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: internet-drafts@ietf.org: New Version Notification for draft-kuehlewind-conex-accurate-ecn-00.txt Content-Disposition: inline Return-Path: X-Original-To: mirja.kuehlewind@ikr.uni-stuttgart.de Delivered-To: mirja.kuehlewind@ikr.uni-stuttgart.de Received: from charon.rus.uni-stuttgart.de (charon.rus.uni-stuttgart.de [129.69.1.54]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id B74B0633B1 for ; Mon, 4 Jul 2011 22:13:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by charon.rus.uni-stuttgart.de (Postfix) with ESMTP id B052C5FDA8 for ; Mon, 4 Jul 2011 22:13:58 +0200 (CEST) X-Virus-Scanned: by amavisd-new at charon.rus.uni-stuttgart.de X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SA2DNSBLC=0.001] autolearn=ham Received: from charon.rus.uni-stuttgart.de ([127.0.0.1]) by localhost (charon.rus.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PQMXiOeLa1qV for ; Mon, 4 Jul 2011 22:13:54 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by charon.rus.uni-stuttgart.de (Postfix) with ESMTP id 229845FDB1 for ; Mon, 4 Jul 2011 22:13:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7070421F87D0; Mon, 4 Jul 2011 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 EPKQAhgd8IWh; Mon, 4 Jul 2011 13:13:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1692021F87D4; Mon, 4 Jul 2011 13:13:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de Cc: rs@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de Subject: New Version Notification for draft-kuehlewind-conex-accurate-ecn-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704201353.26689.17673.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 13:13:53 -0700 A new version of I-D, draft-kuehlewind-conex-accurate-ecn-00.txt has been s= uccessfully submitted by Mirja Kuehlewind and posted to the IETF repository. Filename: draft-kuehlewind-conex-accurate-ecn Revision: 00 Title: Accurate ECN Feedback in TCP Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 23 Abstract: Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. = = The IETF Secretariat --Boundary-00=_LtBFOgXDuyeOOHv Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: internet-drafts@ietf.org: New Version Notification for draft-kuehlewind-conex-tcp-modifications-00.txt Content-Disposition: inline Return-Path: X-Original-To: mirja.kuehlewind@ikr.uni-stuttgart.de Delivered-To: mirja.kuehlewind@ikr.uni-stuttgart.de Received: from medousa.rus.uni-stuttgart.de (medousa.rus.uni-stuttgart.de [129.69.1.57]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9DAC8633B1 for ; Mon, 4 Jul 2011 22:24:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by medousa.rus.uni-stuttgart.de (Postfix) with ESMTP id 965C037ED1 for ; Mon, 4 Jul 2011 22:24:41 +0200 (CEST) X-Virus-Scanned: by amavisd-new at medousa.rus.uni-stuttgart.de X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SA2DNSBLC=0.001] autolearn=ham Received: from medousa.rus.uni-stuttgart.de ([127.0.0.1]) by localhost (medousa.rus.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id P-xXL5nnhWJy for ; Mon, 4 Jul 2011 22:24:37 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by medousa.rus.uni-stuttgart.de (Postfix) with ESMTP id F287637EC4 for ; Mon, 4 Jul 2011 22:24:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0FE11E8122; Mon, 4 Jul 2011 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 n1riBq1sjv9r; Mon, 4 Jul 2011 13:24:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327511E8126; Mon, 4 Jul 2011 13:24:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de Cc: rs@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de Subject: New Version Notification for draft-kuehlewind-conex-tcp-modifications-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704202425.30393.70946.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 13:24:25 -0700 A new version of I-D, draft-kuehlewind-conex-tcp-modifications-00.txt has b= een successfully submitted by Mirja Kuehlewind and posted to the IETF repos= itory. Filename: draft-kuehlewind-conex-tcp-modifications Revision: 00 Title: TCP modifications for Congestion Exposure Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 13 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). = = The IETF Secretariat --Boundary-00=_LtBFOgXDuyeOOHv-- From bob.briscoe@bt.com Wed Jul 6 02:08: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 768C821F871E for ; Wed, 6 Jul 2011 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqTzdYDIZ-nK for ; Wed, 6 Jul 2011 02:08:13 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id B85DB21F85FA for ; Wed, 6 Jul 2011 02:08:12 -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); Wed, 6 Jul 2011 10:08:10 +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); Wed, 6 Jul 2011 10:08:10 +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 1309943289202; Wed, 6 Jul 2011 10:08:09 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.65.44]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p66983l1020124; Wed, 6 Jul 2011 10:08:03 +0100 Message-Id: <201107060908.p66983l1020124@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jul 2011 10:07:56 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: References: <201107050911.p659BXY8013753@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_147646324==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 06 Jul 2011 09:08:10.0577 (UTC) FILETIME=[3A5A0410:01CC3BBC] Cc: "conex@ietf.org" Subject: [conex] conex-abstract-mech flow state 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, 06 Jul 2011 09:08:17 -0000 --=====================_147646324==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, [I've changed the subject line to be more relevant.] Inline... At 06:18 06/07/2011, Georgios Karagiannis wrote: >Hi Bob, > >Thank you very much for the detailed explanation. > >I will try to explain my thoughts on why I think that a Conex congestion >policer needs per flow state. > >The main solution proposed in [draft-ietf-conex-abstract-mech-01] to >audit Conex Signals against actual losses (i.e., the measured congestion >rate) an auditor could use one of the following tecniques "The auditor >could monitor TCP flows or aggregates of flows, only holding state on a >flow if it first sends a Credit or a Re-Echo-Loss marking. The auditor >could detect retransmissions by monitoring sequence numbers. It would >assure that (volume of retransmitted data) <= (volume of data marked >Re-Echo-Loss). Traffic would only be auditable in this way if it >conformed to the standard TCP protocol and the IP payload was not >encrypted (e.g. with IPsec). ", from >[draft-ietf-conex-abstract-mech-01]. > > In other words, an audit device needs to keep per flow (individual or >aggregated) state after it receives a credit or Re-echo-Loss marking in >order to measure the per flow congestion rate. In addition to this the >audit device must be able to read the TCP header in order to observe the >TCP header numbers. This is complex to be implemented and it is not >always possible, e.g., when the IP payload is encrypted (e.g. with >IPsec). In this way, the audit device is also able to take into >consideration also the number of ECN CE marked packets that were dropped >by nodes located upstream. A/ Flow state _____________ Any audit device needs to keep per flow state. I've said that all along at the IETF (since the very first presentation of re-ECN at a BoF in Nov 2005). But, be careful not to just use buzz-word evaluation: There are three potential problems with flow-state in the network: a. Scalability and cost of required memory b. Vulnerability to memory exhaustion attacks c. Vulnerability to source spoofing d. Violation of the shared-fate design principle We have designed two audit functions (and implemented one) that hold flow state but avoid problems 'b', 'c' and 'd' by design. They still have problem 'a' though. B/ TCP seq nos ______________ You are confusing what audit *needs* with what one type of audit *uses*. Let me explain: Abstract-mech describes three possible ways to implement audit. In draft-01 they are in S.2 under the para starting "It is important to note that the auditing requirement..." at the first bullet and the second two sub-bullets. So let's call them: #1 (ECN-based), [has been implemented] #2a (loss-based TCP-only) [not implemented yet] #2b (loss-based, single-bottleneck, transport oblivious) [not implemented yet] Design #1 & #2b prove that: * Audit does not NEED to read TCP sequence numbers. Design #2a USES TCP sequence numbers. It has disadvantages mentioned in abstract-mech (mainly it's specific to TCP and the source can make it ineffective by using IPsec). But its advantage is that it can be placed near the ingress, so it could be useful for initial deployment. But if it started to be the target of attacks, it has vulnerabilities. Then audit would have to be done at the egress using #2b or #1. C/ More on flow state _____________________ All the designs so far have not been able to avoid using flow-state. Therefore we can tentatively say: a: Audit NEEDS to read either the flow 5-tuple or SPI (if IPsec). We can't be sure though. Just because all current designs need a flow ID, does not say that a design without flow ID can never be invented. Nonethelss, we have avoided the three other problems with flow-state: b: By introducing credit packets into the ConEx protocol, the audit device can protect itself against memory exhaustion attacks c: Audit does not NEED the source address or port to be true (ie routable). It just uses it as a uniqueness label. Audit designs #1 & #2b are invulnerable to source spoofing, even different spoofs on each packet. d: Audit designs #1 & #2b use soft-state in the ConEx markings of packets. So if a flow moves to a different audit device on a different path, the state automatically gets recreated on the second audit device. The same happens if one audit device fails (e.g. power off) and another takes over. > Now regarding the Conex congestion policer, >[draft-ietf-conex-abstract-mech-01] specifies: "A congestion policer >can be implemented in a very similar way to a bit-rate policer, but its >effect can be focused solely on traffic causing congestion downstream, >which ConEx signals make visible. Without ConEx signals, the only way to >mitigate congestion is to blindly limit traffic bit-rate, on the >assumption that high bit-rate is more likely to cause congestion. >A congestion policer monitors all ConEx traffic entering a network, or >some identifiable subset. Using ConEx signals, it measures the amount >of congestion that this traffic is contributing to somewhere downstream. > If this exceeds a policy-configured 'congestion-bit-rate' the >congestion policer will limit all the monitored ConEx traffic.", from >from [draft-ietf-conex-abstract-mech-01]. > > My concern is related to the fact that the conex congestion plolicer >will use ConEx signals, as a prediction of the amount of congestion that >this traffic is contributing to somewhere downstream, and then police >traffic. Note that policing traffic might severely affect the rate >behaviour of traffic. > >What I am actually saying is that in the downstream path from a sender >towards the Conex congestion policer data packets will be dropped and >lost. These lost packets contribute to the amount of congestion that >this traffic is contributing to somewhere downstream, but they are not >represented by the received Conex Signals. Thus the Conex Policer will >police traffic based on a somehow inaccurate prediction of the amount of >congestion that this traffic is contributing to somewhere downstream. Despite your confusing use of the word downstream, I think I know what you mean. You mean that the policer only handles congestion downstream of itself, not upstream of itself? That is a deliberate design choice. The insight that originally started the whole re-feedback effort and also the ConEx charter, is that a policer at the ingress to network A doesn't care about congestion in the network(s) upstream of it. Network A thinks "That is your network; that is your problem, not my problem." Nonetheless, if Network A wants to care about your home network, the ConEx *protocol* allows different *policer* design choices. - The protocol is for standardisation. - The policer design is an *example*. The ConEx protocol gives the policer information about congestion both upstream and downstream of itself. So the policer COULD police congestion in your home, on your behalf. That would just be a different policer design. But you would need to justify why you want your network provider to decide what you do in your own home. If you like that idea, well... >In >http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt >it is explained that this inaccuracy could be solved by using the same >method as the one applied in audit devices, i.e., using per flow state >and measuring the rate of lost packets associated with a certain flow. >In this way the Conex congestion policer can use the information provided >by the Conex Signals and the rate of lost packets to accurately predict >the amount of congestion that this traffic is contributing to somewhere >downstream BTW, when you are talking about a policer, it is confusing to say 'downstream' when you mean downstream of somewhere else (ie downstream of the sender). It would be clearer to say 'whole path' in that case. > So the open issues associated with these concerns are: > > What is the accuracy of the Conex Signals on representing the amount of >congestion that traffic is contributing to somewhere downstream? I suspect you mean "somewhere downstream of the sender (not the policer)" If you mean that, you just measure the ConEx markings. They reflect losses along the whole path. So it's accurate. No problem. No issue. To measure congestion downstream of itself, the policer subtracts ECN markings (if available) from ConEx markings. That's accurate too. No problem. No issue. If there's no ECN in the home network, the policer can only measure whole path congestion (downstream of the sender if you really prefer this confusing terminology). That's what you seem to want. But it's not what the w-g is designing for. So it's accurate for your requirement. But for everyone else's requirement, the policer accounts for losses in the home network, which we don't want it to. But the inaccuracy in our case is in the safe direction. * If the home does not deploy ECN, the network polices it more than it needs to. * If the home wants the network to police it less, it should deploy ECN. > How the location of the Congestion Policer and Audit devices influence >the accuracy of the Conex Signals? > > It will be great if these open issues could be clarified in both drafts >(use cases and [draft-ietf-conex-abstract-mech-01]) I believe I have shown these aren't open issues. They come from you wanting to do something different from the charter. I'm going to stop doing tutorial emails now. I have work to do on drafts. Bob >Best regards, >Georgios > > > > > > >On 7/5/2011, "Bob Briscoe" wrote: > > >Georgios, > > > >[Mike, I've also directed this response to you - please see "{Note > >1}" inline that answers a question I recall you asked months ago. I > >don't think I ever answered it - probably got distracted by something.] > > > >At 19:45 04/07/2011, Georgios Karagiannis wrote: > >>Hi Bob, > >> > >>Please see in line! > >> > >>On 7/4/2011, "Bob Briscoe" wrote: > >> > >> >Georgios, > >> > > >> >Yes, it's true that domains wouldn't act on unverifiable information. > >> > > >> >ConEx is designed to solve that problem; to provide downstream > >> >congestion measurements at domain boundaries that are verifiable and > >> >that can be used in bulk without per-flow processing or state. > >> > > >> >To achieve that, unfortunately we still need the ConEx audit > >> >function, which no-one has yet been able to do without per-flow > >> >state. > >> > >>Georgios: Is it not necessay to use a policer? > > > >Three points: > >a) I assume you are using the terms 'policer' and 'audit function' as > >in conex-abstract-mech? > >b) It isn't necessary to use a policer between networks. Indeed, I > >would not recommend a policer between two networks that both use > >ConEx info to protect their respective networks.{Note 1} A traffic > >contract with penalties for sending too much congestion will be sufficient. > >c) A policer does not need to use flow-state. It can act on the bulk > >of traffic passing from the consumer to their ingress network. > > > >> > However, very importantly: > >> >- per-flow ConEx audit is only necessary at the last egress edge of > >> >the internetwork. Every flow does not need to be checked at borders. > >> > >>Georgios: Okay, but I assume that whenever the congestion rate needs to > >>be measured, then a per-flow state is needed. > > > >Not at all. Just like bit-rate, congestion rate is a metric that can > >measure any granularity: flows, aggregates or all the traffic on a > >link. ConEx markings are designed to correctly characterise the > >amount of traffic causing congestion at any granularity - without > >having to measure at finer granularities and add them up. > > > >For instance, a "congestion token bucket policer" measures the > >congestion rate and it can be applied at the granularity of a link > >without looking at flows. Just like a normal token bucket can be > >applied without looking at flows. Whenever a ConEx marked packet > >arrives, tokens are removed from this bucket, without caring about flows. > > > >>Please check the following > >>draft that somehow tries to describe this issue: > >>http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt > > > >Ah! Your draft *assumes* that the congestion rate is being measured > >per flow, then essentially it says it would be complex to measure the > >congestion rate per flow. > > > >I think you've seriously misunderstood. Although ConEx *could* be > >used to make sure individual flows conform to the TCP behaviour, that > >is neither necessary nor the goal. In fact it is a non-goal.{Note 2} > > > >The argument is that it would actually be very wrong to try to get > >flows to conform to the TCP behaviour. Embedding such policers in the > >network would prevent future evolution of better congestion controls. > > > >I will add this to the list of misconceptions in conex-uses. > > > > > >> >- ConEx audit does not aim to control the rate behaviour of flows, it > >> >is solely a per-flow information check. This means no-one needs to > >> >define how individual flows should behave, which is an important > >> achievement. > >> > >>Georgios: okay, but I assume that when a policer is used, then the > >>control of the rate behaviour will be affected! > > > >Of course. But if it is a bulk policer, it only limits the bulk rate > >- it imposes the same level of discard for all flows. > > > >If the audit function detects non-compliance, it will drop packets > >from the non-complying flow(s), which of course reduces their rate. > >But this is to make the outgoing congestion *information* compliant, > >not because it has a particular view of how each flow should make > >their rate respond to congestion. This complies with the requirement > >in conex-abstract-mech: > > > >"Transport Oblivious: > >Audit MUST NOT be designed around one particular rate response, such > >as any particular TCP congestion control algorithm or one particular > >resource sharing regime such as TCP-friendliness > > t-ietf-conex-abstract-mech-01.html#RFC3448>[RFC3448]. > >An important goal is to give ingress networks the freedom to > >unilaterally allow different rate responses to congestion and > >different resource sharing regimes > > t-ietf-conex-abstract-mech-01.html#Evol_cc>[Evol_cc], > >without having to coordinate with downstream networks; " > > > >[BTW, when I talk about the audit function, you keep switching to the > >policing function. Are you sure you are using the terms as defined in > >conex-abstract-mech?] > > > >> > > >> >ConEx audit checks on a per-flow basis that signalling of expected > >> >congestion is no less than actual congestion. This ensures the > >> >integrity of the ConEx information so that it can be used for traffic > >> >management in bulk, e.g at domain boundaries or at the boundary with > >> >the consumer at the sender end. > >> > > >> >(Of course, a network operator could still choose to do per-flow > >> >traffic management. However if their goal is to control traffic cost > >> >or to control one consumer's impact on others it is sufficient for a > >> >network operator to use ConEx information to manage traffic behaviour > >> >in bulk, not per flow.) > >> > >>Georgios: Do you mean that Conex will not require the use of a per-flow > >>policer? > > > >Very definitely yes. That is the main goal of the whole exercise. If > >you missed this point, I can understand why you wrote your draft. > >This is why I have been arguing that conex-concepts-uses needs to say > >what we are NOT trying to do. > > > >Footnotes > >_________ > >{Note 1}: If only the downstream network uses ConEx, then it may not > >be able to get the upstream network to agree to a traffic contract > >that includes ConEx information. But it would still want to deploy a > >ConEx policer at the border. > > > >This policer could choose not to use flow-state. However, then one > >upstream sender could cause the policer to hurt traffic from other > >upstream senders. Two possibilities: > >i) The downstream network might say to the upstream network "Tough, > >if you want to protect your users from DoS attackers on your network, > >police them using ConEx info." > >ii) However, more likely, the downstream network will want a > >congestion policer that does some sampling to detect ConEx flows that > >are causing excessive congestion, and it will separate them out to be > >the ones that discards are focused on whenever the whole bulk of > >traffic is out of contract. > > > >If a DoS attacker was spoofing different source addresses, this > >policer could do full per-flow processing (like DoS protection does > >today). Then it would be easy to discard any packets that say they > >are ConEx enabled but belong to a flow that has not started with > >sufficient positive ConEx markings (green or black). For instance > >ConEx-enabled SYNs without a 'green' marking could automatically > be discarded. > > > >But if I was the downstream network, I would charge the upstream > >network for sorting out their DoS problems for them (that would pay > >for the equipment I would buy to do all this flow-processing). If > >they don't want to pay, they always have option (i) available to them. > > > >Option (i) is the goal, because once the upstream network deploys a > >ConEx policer at the ingress from the sender's network, it doesn't > >need to do flow processing. If any DoS sources within the sender's > >network affect other traffic from that same sender, the problem is > >confined to the sending network hurting itself. > > > >{Note 2}: The original SIGCOMM paper on re-feedback may have caused > >your confusion. Because the prevailing religion of most SIGCOMM > >reviewers at the time assumed the goal was to police individual TCP > >behaviour, to get the paper accepted we had to show that re-feedback > >could do this. But then we showed you didn't need to in a following > >section (a later paper "Policing Freedom..." focused on bulk policing). > > > >If the source of confusion was one of the current ConEx w-g > >documents, not this SIGCOMM paper, please say. We will need to fix that. > > > >Cheers > > > > > > > >Bob > > > >>Best regards, > >>Georgios > >> > >> > > >> > > >> > > >> >Bob > >> > > >> >At 07:39 01/07/2011, Georgios Karagiannis wrote: > >> >>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 > >> >>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] > >> >> >> 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 > >> >> >> > >> >> >> 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 > >> >> >> > >> >> >> _______________________________________________ > >> >> >> 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 --=====================_147646324==.ALT Content-Type: text/html; charset="us-ascii" Georgios,

[I've changed the subject line to be more relevant.] Inline...

At 06:18 06/07/2011, Georgios Karagiannis wrote:

Hi Bob,

Thank you very much for the detailed explanation.

I will try to explain my thoughts on why I think that a Conex congestion
policer needs per flow state.

The main solution proposed in [draft-ietf-conex-abstract-mech-01] to
audit Conex Signals against actual losses (i.e., the measured congestion
rate) an auditor could use one of the following tecniques "The auditor
could monitor TCP flows or aggregates of flows, only holding state on a
flow if it first sends a Credit or a Re-Echo-Loss marking. The auditor
could detect retransmissions by monitoring sequence numbers.  It would
assure that (volume of retransmitted data) <= (volume of data marked
Re-Echo-Loss).  Traffic would only be auditable in this way if it
conformed to the standard TCP protocol and the IP payload was not
encrypted (e.g. with IPsec). ", from
[draft-ietf-conex-abstract-mech-01].

  In other words, an audit device needs to keep per flow (individual or
aggregated) state after it receives a credit or Re-echo-Loss marking in
order to measure the per flow congestion rate. In addition to this  the
audit device must be able to read the TCP header in order to observe the
TCP header numbers. This is complex to be implemented and it is not
always possible, e.g., when the IP payload is encrypted (e.g. with
IPsec). In this way, the audit device is also able to take into
consideration also the number of ECN CE marked packets that were dropped
by nodes located upstream.

A/ Flow state
_____________
Any audit device needs to keep per flow state. I've said that all along at the IETF (since the very first presentation of re-ECN at a BoF in Nov 2005).

But, be careful not to just use buzz-word evaluation:

There are three potential problems with flow-state in the network:
a. Scalability and cost of required memory
b. Vulnerability to memory exhaustion attacks
c. Vulnerability to source spoofing
d. Violation of the shared-fate design principle

We have designed two audit functions (and implemented one) that hold flow state but avoid problems 'b', 'c' and 'd' by design. They still have problem 'a' though.

B/ TCP seq nos
______________
You are confusing what audit *needs* with what one type of audit *uses*. Let me explain:

Abstract-mech describes three possible ways to implement audit.
In draft-01 they are in S.2 under the para starting
        "
It is important to note that the auditing requirement...
"
at the first bullet and the second two sub-bullets. So let's call them:
#1 (ECN-based), [has been implemented]
#2a (loss-based TCP-only) [not implemented yet]
#2b (loss-based, single-bottleneck, transport oblivious) [not implemented yet]

Design #1 & #2b prove that:
* Audit does not NEED to read TCP sequence numbers.
Design #2a USES TCP sequence numbers.
It has disadvantages mentioned in abstract-mech (mainly it's specific to TCP and the source can make it ineffective by using IPsec). But its advantage is that it can be placed near the ingress, so it could be useful for initial deployment. But if it started to be the target of attacks, it has vulnerabilities. Then audit would have to be done at the egress using #2b or #1.

C/ More on flow state
_____________________
All the designs so far have not been able to avoid using flow-state. Therefore we can tentatively say:
a: Audit NEEDS to read either the flow 5-tuple or SPI (if IPsec).

We can't be sure though. Just because all current designs need a flow ID, does not say that a design without flow ID can never be invented.

Nonethelss, we have avoided the three other problems with flow-state:

b: By introducing credit packets into the ConEx protocol, the audit device can protect itself against memory exhaustion attacks

c: Audit does not NEED the source address or port to be true (ie routable). It just uses it as a uniqueness label. Audit designs #1 & #2b are invulnerable to source spoofing, even different spoofs on each packet.

d: Audit designs #1 & #2b use soft-state in the ConEx markings of packets. So if a flow moves to a different audit device on a different path, the state automatically gets recreated on the second audit device. The same happens if one audit device fails (e.g. power off) and another takes over.



 Now regarding the Conex congestion policer,
[draft-ietf-conex-abstract-mech-01] specifies: "A congestion policer
can be implemented in a very similar way to a bit-rate policer, but its
effect can be focused solely on traffic causing congestion downstream,
which ConEx signals make visible. Without ConEx signals, the only way to
mitigate congestion is to blindly limit traffic bit-rate, on the
assumption that high bit-rate is more likely to cause congestion.
A congestion policer monitors all ConEx traffic entering a network, or
some identifiable subset.  Using ConEx signals, it measures the amount
of congestion that this traffic is contributing to somewhere downstream.
 If this exceeds a policy-configured 'congestion-bit-rate' the
congestion policer will limit all the monitored ConEx traffic.", from
from [draft-ietf-conex-abstract-mech-01].

 My concern is related to the fact that the conex congestion plolicer
will use ConEx signals, as a prediction of the amount of congestion that
this traffic is contributing to somewhere downstream, and then police
traffic. Note that policing traffic might severely affect the rate
behaviour of traffic.

What I am actually saying is that in the downstream path from a sender
towards the Conex congestion policer data packets will be dropped and
lost. These lost packets contribute to the amount of congestion that
this traffic is contributing to somewhere downstream, but they are not
represented by the received Conex Signals. Thus the Conex Policer will
police traffic based on a somehow inaccurate prediction of the amount of
congestion that this traffic is contributing to somewhere downstream.

Despite your confusing use of the word downstream, I think I know what you mean. You mean that the policer only handles congestion downstream of itself, not upstream of itself?

That is a deliberate design choice.

The insight that originally started the whole re-feedback effort and also the ConEx charter, is that a policer at the ingress to network A doesn't care about congestion in the network(s) upstream of it. Network A thinks "That is your network; that is your problem, not my problem."

Nonetheless, if Network A wants to care about your home network, the ConEx *protocol* allows different *policer* design choices.
- The protocol is for standardisation.
- The policer design is an *example*.

The ConEx protocol gives the policer information about congestion both upstream and downstream of itself. So the policer COULD police congestion in your home, on your behalf. That would just be a different policer design.

But you would need to justify why you want your network provider to decide what you do in your own home. If you like that idea, well...

In
http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt
it is explained that this inaccuracy could be solved by using the same
method as the one applied in audit devices, i.e., using per flow state
and measuring the rate of lost packets associated with a certain flow.
In this way the Conex congestion policer can use the information provided
by the Conex Signals and the rate of lost packets to accurately predict
the amount of congestion that this traffic is contributing to somewhere
downstream

BTW, when you are talking about a policer, it is confusing to say 'downstream' when you mean downstream of somewhere else (ie downstream of the sender). It would be clearer to say 'whole path' in that case.


 So the open issues associated with these concerns are:

 What is the accuracy of the Conex Signals on representing the amount of
congestion that traffic is contributing to somewhere downstream?

I suspect you mean "somewhere downstream of the sender (not the policer)"

If you mean that, you just measure the ConEx markings. They reflect losses along the whole path.
So it's accurate. No problem. No issue.

To measure congestion downstream of itself, the policer subtracts ECN markings (if available) from ConEx markings.
That's accurate too. No problem. No issue.

If there's no ECN in the home network, the policer can only measure whole path congestion (downstream of the sender if you really prefer this confusing terminology). That's what you seem to want. But it's not what the w-g is designing for.
So it's accurate for your requirement. But for everyone else's requirement, the policer accounts for losses in the home network, which we don't want it to.

But the inaccuracy in our case is in the safe direction.
* If the home does not deploy ECN, the network polices it more than it needs to.
* If the home wants the network to police it less, it should deploy ECN.


 How the location of the Congestion Policer and Audit devices influence
the accuracy of the Conex Signals?

 It will be great if these open issues could be clarified in both drafts
(use cases and [draft-ietf-conex-abstract-mech-01])

I believe I have shown these aren't open issues. They come from you wanting to do something different from the charter.

I'm going to stop doing tutorial emails now. I have work to do on drafts.


Bob


Best regards,
Georgios






On 7/5/2011, "Bob Briscoe" <bob.briscoe@bt.com> wrote:

>Georgios,
>
>[Mike, I've also directed this response to you - please see "{Note
>1}" inline that answers a question I recall you asked months ago. I
>don't think I ever answered it - probably got distracted by something.]
>
>At 19:45 04/07/2011, Georgios Karagiannis wrote:
>>Hi Bob,
>>
>>Please see in line!
>>
>>On 7/4/2011, "Bob Briscoe" <bob.briscoe@bt.com> wrote:
>>
>> >Georgios,
>> >
>> >Yes, it's true that domains wouldn't act on unverifiable information.
>> >
>> >ConEx is designed to solve that problem; to provide downstream
>> >congestion measurements at domain boundaries that are verifiable and
>> >that can be used in bulk without per-flow processing or state.
>> >
>> >To achieve that, unfortunately we still need the ConEx audit
>> >function, which no-one has yet been able to do without per-flow
>> >state.
>>
>>Georgios: Is it not necessay to use a policer?
>
>Three points:
>a) I assume you are using the terms 'policer' and 'audit function' as
>in conex-abstract-mech?
>b) It isn't necessary to use a policer between networks. Indeed, I
>would not recommend a policer between two networks that both use
>ConEx info to protect their respective networks.{Note 1} A traffic
>contract with penalties for sending too much congestion will be sufficient.
>c) A policer does not need to use flow-state. It can act on the bulk
>of traffic passing from the consumer to their ingress network.
>
>> > However, very importantly:
>> >- per-flow ConEx audit is only necessary at the last egress edge of
>> >the internetwork. Every flow does not need to be checked at borders.
>>
>>Georgios: Okay, but I assume that whenever the congestion rate needs to
>>be measured, then a per-flow state is needed.
>
>Not at all. Just like bit-rate, congestion rate is a metric that can
>measure any granularity: flows, aggregates or all the traffic on a
>link. ConEx markings are designed to correctly characterise the
>amount of traffic causing congestion at any granularity - without
>having to measure at finer granularities and add them up.
>
>For instance, a "congestion token bucket policer" measures the
>congestion rate and it can be applied at the granularity of a link
>without looking at flows. Just like a normal token bucket can be
>applied without looking at flows. Whenever a ConEx marked packet
>arrives, tokens are removed from this bucket, without caring about flows.
>
>>Please check the following
>>draft that somehow tries to describe this issue:
>> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt
>
>Ah! Your draft *assumes* that the congestion rate is being measured
>per flow, then essentially it says it would be complex to measure the
>congestion rate per flow.
>
>I think you've seriously misunderstood. Although ConEx *could* be
>used to make sure individual flows conform to the TCP behaviour, that
>is neither necessary nor the goal. In fact it is a non-goal.{Note 2}
>
>The argument is that it would actually be very wrong to try to get
>flows to conform to the TCP behaviour. Embedding such policers in the
>network would prevent future evolution of better congestion controls.
>
>I will add this to the list of misconceptions in conex-uses.
>
>
>> >- ConEx audit does not aim to control the rate behaviour of flows, it
>> >is solely a per-flow information check. This means no-one needs to
>> >define how individual flows should behave, which is an important
>> achievement.
>>
>>Georgios: okay, but I assume that when a policer is used, then the
>>control of the rate behaviour will be affected!
>
>Of course. But if it is a bulk policer, it only limits the bulk rate
>- it imposes the same level of discard for all flows.
>
>If the audit function detects non-compliance, it will drop packets
>from the non-complying flow(s), which of course reduces their rate.
>But this is to make the outgoing congestion *information* compliant,
>not because it has a particular view of how each flow should make
>their rate respond to congestion. This complies with the requirement
>in conex-abstract-mech:
>
>"Transport Oblivious:
>Audit MUST NOT be designed around one particular rate response, such
>as any particular TCP congestion control algorithm or one particular
>resource sharing regime such as TCP-friendliness
>< http://www.jungle.bt.co.uk/people/rbriscoe/ext/projects/conex/draft-ietf-conex-abstract-mech-01.html#RFC3448 >[RFC3448].
>An important goal is to give ingress networks the freedom to
>unilaterally allow different rate responses to congestion and
>different resource sharing regimes
>< http://www.jungle.bt.co.uk/people/rbriscoe/ext/projects/conex/draft-ietf-conex-abstract-mech-01.html#Evol_cc>[Evol_cc ],
>without having to coordinate with downstream networks; "
>
>[BTW, when I talk about the audit function, you keep switching to the
>policing function. Are you sure you are using the terms as defined in
>conex-abstract-mech?]
>
>> >
>> >ConEx audit checks on a per-flow basis that signalling of expected
>> >congestion is no less than actual congestion. This ensures the
>> >integrity of the ConEx information so that it can be used for traffic
>> >management in bulk, e.g at domain boundaries or at the boundary with
>> >the consumer at the sender end.
>> >
>> >(Of course, a network operator could still choose to do per-flow
>> >traffic management. However if their goal is to control traffic cost
>> >or to control one consumer's impact on others it is sufficient for a
>> >network operator to use ConEx information to manage traffic behaviour
>> >in bulk, not per flow.)
>>
>>Georgios: Do you mean that Conex will not require the use of a per-flow
>>policer?
>
>Very definitely yes. That is the main goal of the whole exercise. If
>you missed this point, I can understand why you wrote your draft.
>This is why I have been arguing that conex-concepts-uses needs to say
>what we are NOT trying to do.
>
>Footnotes
>_________
>{Note 1}: If only the downstream network uses ConEx, then it may not
>be able to get the upstream network to agree to a traffic contract
>that includes ConEx information. But it would still want to deploy a
>ConEx policer at the border.
>
>This policer could choose not to use flow-state. However, then one
>upstream sender could cause the policer to hurt traffic from other
>upstream senders. Two possibilities:
>i) The downstream network might say to the upstream network "Tough,
>if you want to protect your users from DoS attackers on your network,
>police them using ConEx info."
>ii) However, more likely, the downstream network will want a
>congestion policer that does some sampling to detect ConEx flows that
>are causing excessive congestion, and it will separate them out to be
>the ones that discards are focused on whenever the whole bulk of
>traffic is out of contract.
>
>If a DoS attacker was spoofing different source addresses, this
>policer could do full per-flow processing (like DoS protection does
>today). Then it would be easy to discard any packets that say they
>are ConEx enabled but belong to a flow that has not started with
>sufficient positive ConEx markings (green or black). For instance
>ConEx-enabled SYNs without a 'green' marking could automatically be discarded.
>
>But if I was the downstream network, I would charge the upstream
>network for sorting out their DoS problems for them (that would pay
>for the equipment I would buy to do all this flow-processing). If
>they don't want to pay, they always have option (i) available to them.
>
>Option (i) is the goal, because once the upstream network deploys a
>ConEx policer at the ingress from the sender's network, it doesn't
>need to do flow processing. If any DoS sources within the sender's
>network affect other traffic from that same sender, the problem is
>confined to the sending network hurting itself.
>
>{Note 2}: The original SIGCOMM paper on re-feedback may have caused
>your confusion. Because the prevailing religion of most SIGCOMM
>reviewers at the time assumed the goal was to police individual TCP
>behaviour, to get the paper accepted we had to show that re-feedback
>could do this. But then we showed you didn't need to in a following
>section (a later paper "Policing Freedom..." focused on bulk policing).
>
>If the source of confusion was one of the current ConEx w-g
>documents, not this SIGCOMM paper, please say. We will need to fix that.
>
>Cheers
>
>
>
>Bob
>
>>Best regards,
>>Georgios
>>
>> >
>> >
>> >
>> >Bob
>> >
>> >At 07:39 01/07/2011, Georgios Karagiannis wrote:
>> >>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
>> >>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" <Michael.Scharf@alcatel-lucent.com>
>> >>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]
>> >> >> 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
>> >> >>
>> >> >> 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" <bob.briscoe@bt.com> 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
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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 --=====================_147646324==.ALT-- From bob.briscoe@bt.com Wed Jul 6 03:13: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 8240F21F8748 for ; Wed, 6 Jul 2011 03:13:25 -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 5vP58ZAI5qEn for ; Wed, 6 Jul 2011 03:13: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 0F9A821F874D for ; Wed, 6 Jul 2011 03:13: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); Wed, 6 Jul 2011 11:13: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); Wed, 6 Jul 2011 11:13:22 +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 1309947201771; Wed, 6 Jul 2011 11:13:21 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.65.44]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p66ADJuK020383; Wed, 6 Jul 2011 11:13:19 +0100 Message-Id: <201107061013.p66ADJuK020383@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jul 2011 11:13:19 +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: 06 Jul 2011 10:13:22.0277 (UTC) FILETIME=[55E81150:01CC3BC5] Subject: [conex] newer intro text: 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: Wed, 06 Jul 2011 10:13:25 -0000 ConEx folks, Following much debate on the previous attempt, below is the hopefully much improved new Intro text intended for draft -02 (deadline Mon 11 July). After the Fig, you'll see I've used fair queuing as the launch pad for the rest of the argument. Rationale for this is at the end of the email if you're interested. My co-editor Rich hasn't seen this (he's just returning from a couple of days away, so for speed I have gone straight to the list). At this stage, please can reviewers suggest changes to specific parts. We won't be able to handle complete re-writes by the deadline. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 1. Introduction The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators usually provide sufficient shared 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]. Referring to Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals'. The sender is then meant to reduce its rate in response. This document provides the entry point to the set of ConEx documentation. It motivates a new congestion exposure (ConEx) field at the IP layer, focusing on the 'why' rather than the 'how'. A companion document about the ConEx protocol mechanism gives the 'how' [ConEx-Abstract-Mech]. Briefly, the idea is for the sender to continually signal expected congestion in the headers of any data it sends. To a first approximation the sender does this by relaying the 'Congestion Feedback Signals' back into the IP layer. They then travel unchanged across the network to the receiver (shown as 'IP- Layer-ConEx-Signals' in Figure 1). Certain IP layer devices can then use this new information, for example as input to traffic management. ,---------. ,---------. |Transport| |Transport| | Sender | . |Receiver | | | /|___________________________________________| | | ,-<---------------Congestion-Feedback-Signals--<--------. | | | |/ | | | | | |\ Transport Layer Feedback Flow | | | | | | \ ___________________________________________| | | | | | \| | | | | | | ' ,-----------. . | | | | | |_____________| |_______________|\ | | | | | | IP Layer | | Data Flow \ | | | | | | |(Congested)| \ | | | | | | | Network |--Congestion-Signals--->-' | | | | | Device | \| | | | | | | /| | | `----------->--(new)-IP-Layer-ConEx-Signals-------->| | | | | | / | | | |_____________| |_______________ / | | | | | | |/ | | `---------' `-----------' ' `---------' Figure 1: Where the ConEx Protocol Fits in the Internet Architecture Briscoe & Woundy Expires January 5, 2012 [Page 3] Internet-Draft ConEx Mechanism July 2011 Current traffic management solutions limit traffic based on either bit-rate or volume. For instance, weighted fair queuing (based on [RFC0970]) shares out bit-rate when a link is congested. However it fails to consider how much of the time a consumer keeps the link busy, which is the main factor that determines everyone else's bit- rate. To try to address this issue, many network operators have introduced volume limits. However, these tend to be either not strict enough during congested periods, or unnecessarily strict when traffic is light. Because each solution only partially addresses the problem, operators keep adding more solutions. So a data path across the Internet often encounters numerous blockages and throttles in each network it crosses. This clutter is actually a symptom of a deeper underlying problem: neither bit-rate nor volume is the right metric. Traffic management would be so much better (and simpler) if congestion were visible in packets. Then, whenever congestion was not present, all restraints could be removed, leaving the full capacity available to everyone. But if some excessive users were causing a lot of congestion, the traffic management function would know and be able to directly limit their traffic, in order to protect the service of other users sharing the same capacity. ConEx exposes exactly the right information for this, in the IP layer. It reveals a consumer's overall contribution to congestion, which is a direct measure of how much one user affects others. ConEx makes this easy to measure--as easy as counting straight volume, except you only count the volume of packets with ConEx markings. With the right metric visible, traffic management would only have to be done once on a path because it would be done well. In the absence of the right metric, some operators have deployed deep packet inspection (DPI) equipment; not just in the public Internet but also in enterprise and campus networks. Their main aim has been to identify and limit specific types of application that they associate with heavy usage. With ConEx, a network operator can manage traffic without dipping into the higher layers, because ConEx makes the relevant bulk congestion information accessible at the IP layer. This solves two problems that have made DPI controversial: traffic management can be application-neutral and compatible with IPsec encryption. 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 quantifiable metric that is open and transparent to both parties, so that it will Briscoe & Woundy Expires January 5, 2012 [Page 4] Internet-Draft ConEx Mechanism July 2011 be sufficient to manage traffic without extra non-transparent wriggle-room and caveats. To summarise so far, ConEx is designed to make it simple to do traffic management that is transparent, neutral and free of unnecessary restraints. Although it is not our place to make a network provider meet these requirements, ConEx is designed to make this the simplest service to provide. {ToDo: review this para when done and fill out} This introduction has focused on traffic management as the main use for ConEx. However, ConEx is intended as a generative technology, with a wider range of potential uses. The document structure reflects this. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Rationale for starting from fair queuing: I was having real trouble with the paras that talked about how volume & bit-rate are the wrong metrics. I originally liked the text Michael Menth suggested and John Leslie improved. But actually, someone could have read them and just said "fair queuing or round-robin scheduling solves that problem; these people are just trying to invent something new, when a solution already exists". The original text I wrote was designed to avoid such criticism, by careful choice of words, but I assume it was consequently unclear given Michael and John both wanted to rewrite it. Therefore, I have tried an approach where we explicitly start from fair queuing, but still try to keep it fairly high level, given this is the introduction. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Jul 6 03:57:07 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 AA2A621F862D for ; Wed, 6 Jul 2011 03:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 Krvy0TQDi2GY for ; Wed, 6 Jul 2011 03:57: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 A897D21F860E for ; Wed, 6 Jul 2011 03:57:06 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 11:57: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); Wed, 6 Jul 2011 11:57: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 1309949823663; Wed, 6 Jul 2011 11:57:03 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.193.51]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p66Av11f020498; Wed, 6 Jul 2011 11:57:01 +0100 Message-Id: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jul 2011 11:57:01 +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: 06 Jul 2011 10:57:05.0266 (UTC) FILETIME=[71546D20:01CC3BCB] Subject: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 06 Jul 2011 10:57:07 -0000 ConEx folks, The proposed table of contents for draft-02 is pasted at the end. Please react if you object. There will be controversy, but please try to recognise that we ought to be converging now. Here's the rationale for the changes. 2. Definitions -> Concepts The "Definitions" section in draft-01 actually introduced the main concepts, which is goal #1 of this doc. So Concepts is a better section heading. Then we've added the much-discussed Misconceptions sub-section clarifying it's not misconceptions about networking, just about ConEx. 5. ConEx Use Cases Removed one use-case (Accounting for Congestion Volume) but really just moved it to "Other Use-Cases" so it can be much shorter. Under "Other Use-Cases", we propose very brief bullets on each of: * Preventing congestion collapse * Accounting for congestion * Interconnection traffic contracts * Provisioning capacity The idea is to resolve all the to-and-fro about which use-cases should be in or out, by having a "half-in" category. And possibly (controversial!) we could then even add... * Mitigating flooding attacks Note also the change of heading: 5.3. ConEx for Intra-Class Quality of Service (QoS) We'll change the story to emphasise that ConEx doesn't replace Diffserv, but it could handle allocation of resources within a class (ie bandwidth allocation as opposed to queue scheduling). 6. Deployment Arrangements. Replaces previous S.5.5. Partial vs. Full Deployment It's tough to talk about deployment in a mechanism-neutral way (given deployment is about deploying mechanisms!). Nonetheless, the idea is to give a plausible story for how the previously mentioned use-cases would get incrementally deployed. So it fits in this doc, but it will be tough. We have summarised stuff about components and incremental deployment in abstract-mech first (I intend to post proposed new text for this section to the list shortly). 7.2. Self Congestion Rather than diving straight into this detailed area early in the Introduction, we've moved it to where it belongs: under 7. Potential Issues. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Common Misconceptions about ConEx . . . . . . . . . . . . 7 3. Traffic Management . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 8 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 9 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 10 5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. ConEx as a basis for traffic management . . . . . . . . . 11 5.2. ConEx to incentivise scavenger transports . . . . . . . . 11 5.3. ConEx for Intra-Class Quality of Service (QoS) . . . . . . 12 5.4. Other Use-Cases . . . . . . . . . . . . . . . . . . . . . 13 6. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 13 6.1. Deployment Concepts . . . . . . . . . . . . . . . . . . . 13 6.2. Single Receiving Network Scenario . . . . . . . . . . . . 14 6.3. Other Initial Deployment Scenarios . . . . . . . . . . . . 14 7. Potential Issues . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Congestion as a Commercial Secret . . . . . . . . . . . . 14 7.2. Self Congestion . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8.1. Information Security . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 18 12. Informative References . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes from previous drafts (to be removed by the RFC Editor) . . . . . . . . . . . . . . . . . . . 19 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Cheers Bob (& discussed with Rich as co-editor, but still some uncertainties - hence asking the list for views) Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Wed Jul 6 04:43: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 1648021F8680 for ; Wed, 6 Jul 2011 04:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AggcsueAH+mP for ; Wed, 6 Jul 2011 04:43:50 -0700 (PDT) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEF221F867C for ; Wed, 6 Jul 2011 04:43:48 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p66Bhf1J019808; Wed, 6 Jul 2011 13:43:41 +0200 From: "Georgios Karagiannis" To: "'Bob Briscoe'" References: <201107050911.p659BXY8013753@bagheera.jungle.bt.co.uk> <201107060908.p66983l1020124@bagheera.jungle.bt.co.uk> In-Reply-To: <201107060908.p66983l1020124@bagheera.jungle.bt.co.uk> Date: Wed, 6 Jul 2011 13:43:41 +0200 Message-ID: <004f01cc3bd1$f45fe270$dd1fa750$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01CC3BE2.B7EB2370" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKrLOmzpD9jNYT7xMi+h9PjxXlRXgK0D6tRAb2Hd9uS/a9u4A== Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: conex@ietf.org Subject: Re: [conex] conex-abstract-mech flow state 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, 06 Jul 2011 11:43:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0050_01CC3BE2.B7EB2370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bob Thank again for the explanations! In order to minimize the discussion points I will answer only to some remarks addressed by you! > Despite your confusing use of the word downstream, I think I know what you mean. > You mean that the policer only handles congestion downstream of itself, not upstream of itself? Georgios: No! According to the text in the [draft-ietf-conex-abstract-mech-01] : "A congestion policer monitors all ConEx traffic entering a network, or some identifiable subset. Using ConEx signals, it measures the amount of congestion that this traffic is contributing to somewhere downstream. If this exceeds a policy-configured 'congestion-bit-rate' the congestion policer will limit all the monitored ConEx traffic.", I can derive the following: The Conex congestion Policer uses the Conex exposure signals to predict the amount of congestion. Based on this, the amount of traffic that contributes to this congestion can be policed/limited by the Conex congestion policer. My point is that this prediction could not be 100% accurate. This is because in the communication paths from different sources to the Conex congestion policer, packets (that carry and do not carry Conex markings) can be dropped. Here we can distinguish some options: (Note: Similar to, RFC3168, I am assuming that some routers may drop ECN-Capable packets while other routers set the CE codepoint, for equivalent levels of congestion. Similarly, a router might drop a non-ECN-Capable packet but set the CE codepoint in an ECN-Capable packet, for equivalent levels of congestion.) o) if packets that do NOT carry Conex Exposure signals are dropped (say dropped_packets_A) AND packets that carry CONEX exposure signals are NOT dropped, then the policer will limit/police more traffic than it should. This is because the policer will not be able to know that the amount dropped_packets_A is already dropped. So the policer will drop erroneously an additional amount of traffic equal to dropped_packets_A . o) if packets that do NOT carry Conex Exposure signals are dropped (say dropped_packets_A) AND packets that carry CONEX exposure signals are also dropped, then the policer will limit/police an amount of traffic that might be different than the targeted amount of traffic that needed to be limited. o) if packets that do NOT carry Conex Exposure signals are NOT dropped (say dropped_packets_A) AND packets that carry CONEX exposure signals are dropped, then the policer will limit/police an amount of traffic that might be different than the targeted amount of traffic that needed to be limited. >> What is the accuracy of the Conex Signals on representing the amount of >> congestion that traffic is contributing to somewhere downstream? >I suspect you mean "somewhere downstream of the sender (not the policer)" >If you mean that, you just measure the ConEx markings. They reflect losses along the whole path. > So it's accurate. No problem. No issue. Georgios: Yes I mean somewhere downstream of the sender. I think however, that there is an accuracy problem with the ability of the CONEX exposure markings to accurately represent the congestion rate on the path from the sender to receiver, see my explanation about the prediction given above. This inaccuracy could be acceptable, I do not know. In order to find this out some investigation is needed. This could be clarified in both drafts (use cases and [draft-ietf-conex-abstract-mech-01]) Best regards, Georgios ------=_NextPart_000_0050_01CC3BE2.B7EB2370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bob

 

Thank again for the explanations!

In order to minimize the discussion points I will answer only to some = remarks addressed by you!

 

> Despite your confusing use of the word = downstream, I think I know what you mean.

> You mean that the policer only = handles congestion downstream of itself, not upstream of = itself?

 

Georgios: No!

According to the text in the = [draft-ietf-conex-abstract-mech-01] :

“A congestion policer = monitors all ConEx traffic entering a network, or
some identifiable = subset.  Using ConEx signals, it measures the amount
of = congestion that this traffic is contributing to somewhere = downstream.
 If this exceeds a policy-configured = 'congestion-bit-rate' the
congestion policer will limit all the = monitored ConEx traffic.",

I can derive the = following:

 

The Conex congestion Policer uses the Conex exposure = signals to predict the amount of congestion.

Based on this, the amount of = traffic that contributes to this congestion can be policed/limited by = the Conex congestion policer.

 

My point is that this prediction = could not be 100% accurate. This is because in the communication paths =

from = different sources to the Conex congestion policer, packets (that carry = and do not carry Conex markings) can be dropped.

 

Here we can distinguish some = options:

(Note: Similar to, RFC3168, I am  assuming that some = routers may drop ECN-Capable packets

while other routers set the CE = codepoint, for equivalent levels of congestion.  Similarly, a = router might drop a non-ECN-Capable packet

but set the CE codepoint in an = ECN-Capable packet, for equivalent  levels of = congestion.)

 

 

o) if packets that do NOT carry Conex Exposure signals are = dropped (say dropped_packets_A) AND packets that carry CONEX exposure = signals are NOT dropped, then the policer will limit/police more traffic = than it should.  This is because the policer will not be able to = know that the amount dropped_packets_A  is already dropped. So the = policer will drop erroneously an additional amount of traffic equal to = dropped_packets_A .

 

o) if packets that do NOT carry Conex Exposure signals are = dropped (say dropped_packets_A) AND packets that carry CONEX exposure = signals are also dropped, then the policer will limit/police an amount = of traffic that might be different than the targeted amount of traffic = that needed to be limited.

 

o) if packets that do NOT carry = Conex Exposure signals are NOT dropped (say dropped_packets_A) AND = packets that carry CONEX exposure signals are dropped, then the policer = will limit/police an amount of traffic that might be different than the = targeted amount of traffic that needed to be = limited.

 

 

 


 >> What is the accuracy of the Conex = Signals on representing the amount of
>> congestion that = traffic is contributing to somewhere downstream?


>I suspect you mean = "somewhere downstream of the sender (not the = policer)"

>If you mean that, you just measure the ConEx = markings. They reflect losses along the whole path.
> So it's = accurate. No problem. No issue.

 

Georgios: Yes I mean somewhere downstream of the sender. I = think however, that there is an accuracy problem with the ability of the = CONEX exposure markings to accurately represent the congestion rate on = the path from the sender to receiver, see my explanation about the = prediction given above.

 

This inaccuracy could be acceptable, I do not know. =

In order = to find this out some investigation is needed.

 

This could be clarified  in = both drafts
(use cases and = [draft-ietf-conex-abstract-mech-01])

 

Best = regards,

Georgios

 

 

------=_NextPart_000_0050_01CC3BE2.B7EB2370-- From karagian@cs.utwente.nl Wed Jul 6 05: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 39B6A21F85A2 for ; Wed, 6 Jul 2011 05:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, 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 LwNqCEDmuErq for ; Wed, 6 Jul 2011 05:26:41 -0700 (PDT) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD121F8593 for ; Wed, 6 Jul 2011 05:26:40 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p66CQY1J013016; Wed, 6 Jul 2011 14:26:34 +0200 From: "Georgios Karagiannis" To: "=?iso-8859-1?Q?'Mirja_K=FChlewind'?=" , References: <201107061022.35695.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201107061022.35695.mkuehle@ikr.uni-stuttgart.de> Date: Wed, 6 Jul 2011 14:26:34 +0200 Message-ID: <008c01cc3bd7$f1cf8be0$d56ea3a0$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLxXC9gsALn5ESz85ZJ3NuZgCbns5KU9bWw Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 12:26:42 -0000 Hi Mirja I have (quickly) read the document = draft-kuehlewind-conex-accurate-ecn-00.=20 So sorry if I have not understood the concept well! The described solution in this draft is based on [draft-briscoe- tsvwg-re-ecn-tcp-09] and is actually used to=20 carry the required feedback from the receiver to the sender such that = the sender could calculate=20 the experienced congestion rate (from sender to receiver). In my opinion this solution being similar to the one proposed in [draft-briscoe- tsvwg-re-ecn-tcp-09] seems to be quite complex to be deployed, since protocol changes need to = be accomplished in order to modify the=20 semantics of the TCP header, i.e., the semantics of the flags: NS, CWR = and ECE. In http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation-00.= txt another solution on=20 calculating the congestion rate at the sender is described where these changes in the semantics of TCP are not required. This document provides a solution to this problem as follows, see=20 Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt When the sender needs to reduce its sending rate, then the sender can=20 calculate the exposed CONGESTION RATE by subtracting the TCP=20 throughput calculated during a Round Trip Time (RTT), i.e., (RTTi)=20 from the TCP throughput calculated at the same sender side during the=20 previous RTT, i.e., (RTTi-1), where i is an integer equal or higher=20 than 1. The TCP throughput at the sender side can be calculated using, e.g.,=20 the following equation specified in [RFC5348]: "The throughput equation for X_Bps, TCP's average sending rate in bytes per second, is: s X_Bps =3D ---------------------------------------------------------- R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))) Where: X_Bps is TCP's average transmit rate in bytes per second. (X_Bps is the same as X_calc in RFC 3448.) s is the segment size in bytes (excluding IP and transport protocol headers). R is the round-trip time in seconds. p is the loss event rate, between 0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted. t_RTO is the TCP retransmission timeout value in seconds. b is the maximum number of packets acknowledged by a single TCP acknowledgement.", copied from [RFC5368].=20 Note that the transport path throughput calculated at the sender is = defined as: The per flow transport sending rate as a function of the congestion rate, round-trip time, and segment size. The transport path throughput calculated at the sender using the TCP throughput equation specified in [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted as loss event rate. According to [RFC5348] a loss event is defined as one = or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication (CE) from Explicit Congestion = Notification (ECN) [RFC3168];=20 Best regards, Georgios > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mirja K=FChlewind > Sent: woensdag 6 juli 2011 10:23 > To: conex@ietf.org > Subject: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hello, >=20 > we submitted two new drafts regarding the needed TCP modifications for > ConEx. > As ConEx relies (partially) on ECN, a more accurate ECN feedback (more than > max. one signal per RTT) is needed. The same information would be > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. This = is > why, we decided to split this modification into a separate and tried = to specify > this independent of ConEx. Thus we have two drafts now: >=20 > 1. draft-kuehlewind-conex-accurate-ecn > This draft currently proposes three different coding scheme to realize = a more > accurate ECN feedback. All approaches use the available 'classic' ECN = bit > space as only one mechanism (classic ECN or the new more accurate = scheme) > is needed at a time. The goal is to chose one of the coding options = and have > the other option and all discussions removed at later version of this draft. >=20 > 2. draft-kuehlewind-conex-tcp-modifications > This draft describes all other modifications/recommendations to use = ConEx > with TCP. This is the use of ECN and SACK and recommendations on the > credit bit. > This document contains several points which need further discussion = e.g. the > handling and validity of credits. >=20 > Please have a look at the drafts; Feedback is very welcome! >=20 > Mirja and Richard From rs@netapp.com Wed Jul 6 07:49: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 2E4CD21F86D1 for ; Wed, 6 Jul 2011 07:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ZySbVYbxLGVW for ; Wed, 6 Jul 2011 07:49:37 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3063321F853A for ; Wed, 6 Jul 2011 07:49:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,487,1304319600"; d="scan'208";a="262608749" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 06 Jul 2011 07:49:27 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p66EnPGd019093; Wed, 6 Jul 2011 07:49:25 -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); Wed, 6 Jul 2011 15:49:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 15:49:04 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E306B@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <008c01cc3bd7$f1cf8be0$d56ea3a0$@cs.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] New draft(s) on TCP modifications for ConEx Thread-Index: AQLxXC9gsALn5ESz85ZJ3NuZgCbns5KU9bWwgAAd7QA= References: <201107061022.35695.mkuehle@ikr.uni-stuttgart.de> <008c01cc3bd7$f1cf8be0$d56ea3a0$@cs.utwente.nl> From: "Scheffenegger, Richard" To: "Georgios Karagiannis" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , X-OriginalArrivalTime: 06 Jul 2011 14:49:25.0212 (UTC) FILETIME=[E62F61C0:01CC3BEB] Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 14:49:38 -0000 Hi Georgios, Thanks for the quick reply. I'm replying as the co-author of this draft. Your comment is only about one (of the three proposed) mechanisms to = signal more accurate ECN feedback. As you have noticed, we introduce = three different signaling encodings and semantics, each with increasing = feature set (and accuracy) over the previous, but also with increasing = complexity at implementation. Also note, that draft-kuehlewind-conex-accurate-ecn-00, even while = submitted in the ConEx WG, really has a broader scope, any deals with = the TCP layer alone. Conex is but one possible framework, where this = more accurate ECN feedback will be required. Submitting this draft to = TCPM was also shortly discussed internally, but ConEx really has a = current demand. Nevertheless, the broader scope (and different = constraints) of TCP should not get lost when discussing this draft. Reading your draft, I fail to understand how this may work. Using = standard RFC3168 feedback, only a single (!) CE per RTT can be signaled, = and then TCP will always react with a single CC response per RTT... = regardless of how many CE marks the receiver actually received during = the RTT following the initial CE. Calculating the sending rate at the sender doesn't seem to accomplish = what you aim at (or the ingenious idea is missing in that draft). With = the widespread adoption of TCP SACK, and alternate congestion controller = responses than NewReno (e.g. CUBIC, Compound, ...), the closed formula = you quote is only a crude guess at the actual sending rate. These newer = TCP congestion control reactions will conform to that formula only under = certain (limited) circumstances, at best. (The formula gives a worst = case estimate, but the typical sending rate will be higher). = Furthermore, the goal of ECN is, to avoid loss (denoted "p" in the = formula) due to congestion as much as possible. Because of the limited = signal bandwidth (one bit per RTT) of RFC3168, compared to congestion = loss (one bit per segment sent - conveyed more or less accurately by = ACKs/SACKs), putting standard ECN feedback into "p" will not work.=20 Furthermore, the congestion volume, if I followed ConEx correctly, is = the volume of bytes (measured as IP-layer bytes, NOT IP payload, or TCP = payload bytes) which were received with CE set. With only a single bit = of feedback per RTT, the congestion volume therefore has a lower bound = of PMTU bytes per RTT (actually, the minimum packet size possible, when = 1-byte TCP payload segments are sent for whatever reason), and an upper = bound of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP = Options])+FlightSize. Your formula would, as it seems to me, always estimate the congestion = volume to be close to cwnd/2 (excluding the IP Header, TCP Headers, and = also excluding the actual number of congestions during that RTT). This = may be a (very) conservative estimate during low congestion periods, but = a very aggressive (=3Dmuch too small) estimate during heavy congestion = periods (e.g. 1 RTT, where each segment is CE marked). Again, the goal for Accurate ECN feedback is to allow an exact (under = common circumstances) feedback of the CE marks as seen by a TCP = receiver, to be sent back to the sender. As TCP can not rely on external = means to enforce honesty (Conex would be one such external means), ECN = Nonce support would be beneficial. One more word w.r.t. complexity: I believe that the gap between network = performance and CPU performance will not shrink in the future. All = developments over the last decade points to an ever widening gap. = Therefore, schemes which couldn't be hoped to have any chance to be = implemented, because of their complexity, such as Conex, are today = running at wirespeed in 10G environments. The times, where one major = design goal of a protocol was to use as few as possible machine = instructions to encode/decode and interpret, are long past. I have seen early SACK and TS work was discussed in terms of number of = machine instructions added to the TCP codepath (which is one piece of = the puzzle to understand why timestamp semantics are defined the way = they are).=20 (Also, calculating the integer square root is more involved than doing = some bit-banging ;) Richard Scheffenegger > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Mittwoch, 06. Juli 2011 14:27 > To: 'Mirja K=FChlewind'; conex@ietf.org > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hi Mirja >=20 > I have (quickly) read the document draft-kuehlewind-conex-accurate- > ecn-00. > So sorry if I have not understood the concept well! >=20 > The described solution in this draft is based on [draft-briscoe- > tsvwg-re-ecn-tcp-09] and is actually used to > carry the required feedback from the receiver to the sender such that > the > sender could calculate > the experienced congestion rate (from sender to receiver). >=20 > In my opinion this solution being similar to the one proposed in > [draft-briscoe- tsvwg-re-ecn-tcp-09] > seems to be quite complex to be deployed, since protocol changes need > to be > accomplished in order to modify the > semantics of the TCP header, i.e., the semantics of the flags: NS, = CWR > and > ECE. >=20 > In > http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation- > 00.txt > another solution on > calculating the congestion rate at the sender is described where > these > changes in the semantics of > TCP are not required. >=20 > This document provides a solution to this problem as follows, see > Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt >=20 > When the sender needs to reduce its sending rate, then the sender can > calculate the exposed CONGESTION RATE by subtracting the TCP > throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) > from the TCP throughput calculated at the same sender side during the > previous RTT, i.e., (RTTi-1), where i is an integer equal or higher > than 1. >=20 > The TCP throughput at the sender side can be calculated using, e.g., > the following equation specified in [RFC5348]: >=20 >=20 > "The throughput equation for X_Bps, TCP's average sending rate in > bytes per second, is: >=20 > s > X_Bps =3D = ---------------------------------------------------------- > R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))) >=20 > Where: >=20 > X_Bps is TCP's average transmit rate in bytes per second. = (X_Bps > is the same as X_calc in RFC 3448.) >=20 > s is the segment size in bytes (excluding IP and transport > protocol headers). >=20 > R is the round-trip time in seconds. >=20 > p is the loss event rate, between 0 and 1.0, of the number of > loss > events as a fraction of the number of packets transmitted. >=20 > t_RTO is the TCP retransmission timeout value in seconds. >=20 > b is the maximum number of packets acknowledged by a single TCP > acknowledgement.", copied from [RFC5368]. >=20 >=20 > Note that the transport path throughput calculated at the sender is > defined > as: The per flow transport sending rate as a function of the = congestion > rate, round-trip time, and segment size. The transport path throughput > calculated at the sender using the TCP throughput equation specified = in > [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted > as > loss event rate. According to [RFC5348] a loss event is defined as one > or > more lost or marked packets from a window of data, where a marked > packet > refers to a congestion indication (CE) from Explicit Congestion > Notification > (ECN) [RFC3168]; >=20 > Best regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > Of Mirja K=FChlewind > > Sent: woensdag 6 juli 2011 10:23 > > To: conex@ietf.org > > Subject: [conex] New draft(s) on TCP modifications for ConEx > > > > Hello, > > > > we submitted two new drafts regarding the needed TCP modifications > for > > ConEx. > > As ConEx relies (partially) on ECN, a more accurate ECN feedback > (more > than > > max. one signal per RTT) is needed. The same information would be > > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. > This is > > why, we decided to split this modification into a separate and tried > to > specify > > this independent of ConEx. Thus we have two drafts now: > > > > 1. draft-kuehlewind-conex-accurate-ecn > > This draft currently proposes three different coding scheme to > realize a > more > > accurate ECN feedback. All approaches use the available 'classic' = ECN > bit > > space as only one mechanism (classic ECN or the new more accurate > scheme) > > is needed at a time. The goal is to chose one of the coding options > and > have > > the other option and all discussions removed at later version of = this > draft. > > > > 2. draft-kuehlewind-conex-tcp-modifications > > This draft describes all other modifications/recommendations to use > ConEx > > with TCP. This is the use of ECN and SACK and recommendations on the > > credit bit. > > This document contains several points which need further discussion > e.g. > the > > handling and validity of credits. > > > > Please have a look at the drafts; Feedback is very welcome! > > > > Mirja and Richard >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Wed Jul 6 09:13: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 6B39F21F8639 for ; Wed, 6 Jul 2011 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zDgTTWh+pNKt for ; Wed, 6 Jul 2011 09:13:45 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7B121F8631 for ; Wed, 6 Jul 2011 09:13:45 -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 DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 479F9888965; Wed, 6 Jul 2011 18:13:42 +0200 (CEST) Message-ID: <4E1489B5.9080406@it.uc3m.es> Date: Wed, 06 Jul 2011 18:13:41 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 'ConEx IETF list' , Bob Briscoe , 'Richard Woundy' , Matt Mathis , Nandita Dukkipati , =?ISO-8859-1?Q?Mirja_K=FChlew?= =?ISO-8859-1?Q?ind?= , Suresh Krishnan 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.8.0.1017-18244.000 Subject: [conex] Draft agenda 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, 06 Jul 2011 16:13:46 -0000 The draft agenda is posted. http://www.ietf.org/proceedings/81/agenda/conex.txt Let me know if there are changes. Regards, marcelo From karagian@cs.utwente.nl Wed Jul 6 12:17: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 983DB21F8AA9 for ; Wed, 6 Jul 2011 12:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.934 X-Spam-Level: X-Spam-Status: No, score=0.934 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, 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 XxnlifrkKKNp for ; Wed, 6 Jul 2011 12:17:27 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1521F8AA3 for ; Wed, 6 Jul 2011 12:17:27 -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 p66JFkrO003757; Wed, 6 Jul 2011 21:15:47 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 19:17:26 +0000 To: "Scheffenegger, Richard" , "Mirja =?ISO-8859-1?Q?K=FChlewind?=" , "conex@ietf.org" Date: Wed, 06 Jul 2011 19:17:25 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F1E306B@LDCMVEXC1-PRD.hq.netapp.com> 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]); Wed, 06 Jul 2011 21:15:59 +0200 (MEST) Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 19:17:28 -0000 Hi Richard, Please see in line! On 7/6/2011, "Scheffenegger, Richard" wrote: > >Hi Georgios, > >Thanks for the quick reply. > >I'm replying as the co-author of this draft. > >Your comment is only about one (of the three proposed) mechanisms to signal = more accurate ECN feedback. As you have noticed, we introduce three different= signaling encodings and semantics, each with increasing feature set (and acc= uracy) over the previous, but also with increasing complexity at implementati= on. Georgios: Yes, sorry for not mentioning them, I was referring to the last two solutions. > >Also note, that draft-kuehlewind-conex-accurate-ecn-00, even while submitted= in the ConEx WG, really has a broader scope, any deals with the TCP layer al= one. Conex is but one possible framework, where this more accurate ECN feedba= ck will be required. Submitting this draft to TCPM was also shortly discussed= internally, but ConEx really has a current demand. Nevertheless, the broader= scope (and different constraints) of TCP should not get lost when discussing= this draft. Georgios: Okay, but my point regarding the fact that the the two latter proposed solutins biy your draft are complex to be deployed, is still valid, since protocol changes need to be accomplished in order to modify the semantics of the TCP header, i.e., the semantics of the flags: NS, CWR and ECE. > > > >Reading your draft, I fail to understand how this may work. Using standard R= FC3168 feedback, only a single (!) CE per RTT can be signaled, and then TCP w= ill always react with a single CC response per RTT... regardless of how many = CE marks the receiver actually received during the RTT following the initial = CE. Georgios: Note that the solution uses the implementation specified in RFC5348. According to this RFC5348, "The receiver periodically sends feedback messages to the sender. Feedback packets SHOULD normally be sent at least once per RTT, unless the sender is sending at a rate of less than one packet per RTT, in which case a feedback packet SHOULD be sent for every data packet received. A feedback packet SHOULD also be sent whenever a new loss event is detected without waiting for the end of an RTT, and whenever an out-of-order data packet is received that removes a loss event from the history. If the sender is transmitting at a high rate (many packets per RTT), there may be some advantages to sending periodic feedback messages more than once per RTT as this allows faster response to changing RTT measurements and more resilience to feedback packet loss." > >Calculating the sending rate at the sender doesn't seem to accomplish what y= ou aim at (or the ingenious idea is missing in that draft). With the widespre= ad adoption of TCP SACK, and alternate congestion controller responses than N= ewReno (e.g. CUBIC, Compound, ...), the closed formula you quote is only a cr= ude guess at the actual sending rate. These newer TCP congestion control reac= tions will conform to that formula only under certain (limited) circumstances= , at best. (The formula gives a worst case estimate, but the typical sending = rate will be higher). Furthermore, the goal of ECN is, to avoid loss (denoted= "p" in the formula) due to congestion as much as possible. Because of the li= mited signal bandwidth (one bit per RTT) of RFC3168, compared to congestion l= oss (one bit per segment sent - conveyed more or less accurately by ACKs/SACK= s), putting standard ECN feedback into "p" will not work.=20 Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) is used by this solution. So the accuracy of the congestion rate calculation will depend on the accuracy of the TFRC. Moreover, according to RFC5348: "The throughput equation currently REQUIRED for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [PFTK98]. Ideally, we would prefer a throughput equation based on selective acknowledgment (SACK) TCP, but no one has yet derived the throughput equation for SACK TCP, and simulations and experiments suggest that the differences between the two equations would be relatively minor [FF99] (Appendix B).", from [RFC5348] Furthermore, note that p is the rate of loss events and is depending on the loss rate. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets. p can be send from receiver towards the sender in feedback packets. In TFRC several feedback packets can be sent towards the sender within one RTT, depending on the sender data rate. > > >Furthermore, the congestion volume, if I followed ConEx correctly, is the vo= lume of bytes (measured as IP-layer bytes, NOT IP payload, or TCP payload byt= es) which were received with CE set. With only a single bit of feedback per R= TT, the congestion volume therefore has a lower bound of PMTU bytes per RTT (= actually, the minimum packet size possible, when 1-byte TCP payload segments = are sent for whatever reason), and an upper bound of floor(FlightSize/MSS)+1*= (IP_Header+TCP_Header[TCP Options])+FlightSize. > >Your formula would, as it seems to me, always estimate the congestion volume= to be close to cwnd/2 (excluding the IP Header, TCP Headers, and also exclud= ing the actual number of congestions during that RTT). This may be a (very) c= onservative estimate during low congestion periods, but a very aggressive (= =3Dmuch too small) estimate during heavy congestion periods (e.g. 1 RTT, wher= e each segment is CE marked). Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) is used by this solution. So the accuracy of the congestion rate calculation will depend on the accuracy of the TFRC. > > > >Again, the goal for Accurate ECN feedback is to allow an exact (under common= circumstances) feedback of the CE marks as seen by a TCP receiver, to be sen= t back to the sender. As TCP can not rely on external means to enforce honest= y (Conex would be one such external means), ECN Nonce support would be benefi= cial. Georgios: Yes I agree it might be beneficial. > > >One more word w.r.t. complexity: I believe that the gap between network perf= ormance and CPU performance will not shrink in the future. All developments o= ver the last decade points to an ever widening gap. Therefore, schemes which = couldn't be hoped to have any chance to be implemented, because of their comp= lexity, such as Conex, are today running at wirespeed in 10G environments. Th= e times, where one major design goal of a protocol was to use as few as possi= ble machine instructions to encode/decode and interpret, are long past. > >I have seen early SACK and TS work was discussed in terms of number of machi= ne instructions added to the TCP codepath (which is one piece of the puzzle t= o understand why timestamp semantics are defined the way they are).=20 > >(Also, calculating the integer square root is more involved than doing some = bit-banging ;) Georgios: I think that you refer to my statement regarding implementation complexity of the Re-ECN solution. The term that I have used is not the correct one. I should have used deployment complexity instead of implmentation complexity. Best regards, Georgios > > >Richard Scheffenegger > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Mittwoch, 06. Juli 2011 14:27 >> To: 'Mirja K=FChlewind'; conex@ietf.org >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >>=20 >> Hi Mirja >>=20 >> I have (quickly) read the document draft-kuehlewind-conex-accurate- >> ecn-00. >> So sorry if I have not understood the concept well! >>=20 >> The described solution in this draft is based on [draft-briscoe- >> tsvwg-re-ecn-tcp-09] and is actually used to >> carry the required feedback from the receiver to the sender such that >> the >> sender could calculate >> the experienced congestion rate (from sender to receiver). >>=20 >> In my opinion this solution being similar to the one proposed in >> [draft-briscoe- tsvwg-re-ecn-tcp-09] >> seems to be quite complex to be deployed, since protocol changes need >> to be >> accomplished in order to modify the >> semantics of the TCP header, i.e., the semantics of the flags: NS, CWR >> and >> ECE. >>=20 >> In >> http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation- >> 00.txt >> another solution on >> calculating the congestion rate at the sender is described where >> these >> changes in the semantics of >> TCP are not required. >>=20 >> This document provides a solution to this problem as follows, see >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt >>=20 >> When the sender needs to reduce its sending rate, then the sender can >> calculate the exposed CONGESTION RATE by subtracting the TCP >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) >> from the TCP throughput calculated at the same sender side during the >> previous RTT, i.e., (RTTi-1), where i is an integer equal or higher >> than 1. >>=20 >> The TCP throughput at the sender side can be calculated using, e.g., >> the following equation specified in [RFC5348]: >>=20 >>=20 >> "The throughput equation for X_Bps, TCP's average sending rate in >> bytes per second, is: >>=20 >> s >> X_Bps =3D ---------------------------------------------------------- >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))) >>=20 >> Where: >>=20 >> X_Bps is TCP's average transmit rate in bytes per second. (X_Bps >> is the same as X_calc in RFC 3448.) >>=20 >> s is the segment size in bytes (excluding IP and transport >> protocol headers). >>=20 >> R is the round-trip time in seconds. >>=20 >> p is the loss event rate, between 0 and 1.0, of the number of >> loss >> events as a fraction of the number of packets transmitted. >>=20 >> t_RTO is the TCP retransmission timeout value in seconds. >>=20 >> b is the maximum number of packets acknowledged by a single TCP >> acknowledgement.", copied from [RFC5368]. >>=20 >>=20 >> Note that the transport path throughput calculated at the sender is >> defined >> as: The per flow transport sending rate as a function of the congestion >> rate, round-trip time, and segment size. The transport path throughput >> calculated at the sender using the TCP throughput equation specified in >> [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted >> as >> loss event rate. According to [RFC5348] a loss event is defined as one >> or >> more lost or marked packets from a window of data, where a marked >> packet >> refers to a congestion indication (CE) from Explicit Congestion >> Notification >> (ECN) [RFC3168]; >>=20 >> Best regards, >> Georgios >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> Behalf >> > Of Mirja K=FChlewind >> > Sent: woensdag 6 juli 2011 10:23 >> > To: conex@ietf.org >> > Subject: [conex] New draft(s) on TCP modifications for ConEx >> > >> > Hello, >> > >> > we submitted two new drafts regarding the needed TCP modifications >> for >> > ConEx. >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback >> (more >> than >> > max. one signal per RTT) is needed. The same information would be >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. >> This is >> > why, we decided to split this modification into a separate and tried >> to >> specify >> > this independent of ConEx. Thus we have two drafts now: >> > >> > 1. draft-kuehlewind-conex-accurate-ecn >> > This draft currently proposes three different coding scheme to >> realize a >> more >> > accurate ECN feedback. All approaches use the available 'classic' ECN >> bit >> > space as only one mechanism (classic ECN or the new more accurate >> scheme) >> > is needed at a time. The goal is to chose one of the coding options >> and >> have >> > the other option and all discussions removed at later version of this >> draft. >> > >> > 2. draft-kuehlewind-conex-tcp-modifications >> > This draft describes all other modifications/recommendations to use >> ConEx >> > with TCP. This is the use of ECN and SACK and recommendations on the >> > credit bit. >> > This document contains several points which need further discussion >> e.g. >> the >> > handling and validity of credits. >> > >> > Please have a look at the drafts; Feedback is very welcome! >> > >> > Mirja and Richard >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Wed Jul 6 12:52: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 8223121F8B73 for ; Wed, 6 Jul 2011 12:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 Bi6I+Y0ZulLi for ; Wed, 6 Jul 2011 12:52:48 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6843321F8AA2 for ; Wed, 6 Jul 2011 12:52:48 -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 p66JpCih011341; Wed, 6 Jul 2011 21:51:13 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 19:52:52 +0000 To: "marcelo bagnulo braun" Date: Wed, 06 Jul 2011 19:52:52 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4E1489B5.9080406@it.uc3m.es> 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]); Wed, 06 Jul 2011 21:51:22 +0200 (MEST) Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 06 Jul 2011 19:52:49 -0000 Hi Marcelo, Is it possible to get a 10 minutes agenda slot for each of the two below dafts: http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion-calculatio= n/ http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt Best regards, Georgios On 7/6/2011, "marcelo bagnulo braun" wrote: >The draft agenda is posted. >http://www.ietf.org/proceedings/81/agenda/conex.txt >Let me know if there are changes. >Regards, marcelo > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From rs@netapp.com Wed Jul 6 12:56: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 11ECF21F8B69 for ; Wed, 6 Jul 2011 12:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 WhdRRIyJzi37 for ; Wed, 6 Jul 2011 12:55:58 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id C904821F8B2A for ; Wed, 6 Jul 2011 12:55:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,488,1304319600"; d="scan'208";a="253590347" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 06 Jul 2011 12:55:56 -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 p66Jtsmp024763; Wed, 6 Jul 2011 12:55:55 -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); Wed, 6 Jul 2011 21:55:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 20:55:33 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E3198@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] New draft(s) on TCP modifications for ConEx Thread-Index: Acw8EXKLiNaY6BHlT6+7+8SC3SqT0wAAa+sg References: <5FDC413D5FA246468C200652D63E627A0F1E306B@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Georgios Karagiannis" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , X-OriginalArrivalTime: 06 Jul 2011 19:55:54.0636 (UTC) FILETIME=[B722CCC0:01CC3C16] Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 19:56:00 -0000 Hi Georgios, So, you are proposing something orthogonal to TCP encoding (DCCP = transports using CCID3/4)? Now this was the part I have been missing. Regarding deployment complexity of accurate-ecn:=20 We envision, that only one signaling/semantic will ultimately be chosen = by the IETF. For that single method, a backwards-compatible handshake is = described (section 2);=20 If accurate ecn semantics are not negotiated between end hosts, a = compatibility mode is also sketched (section 3.4). This approach allows = to extract more than one bit per RTT as ECN feedback from regular = RFC3168 tcp receivers. While in that state, the sender itself would = obviously adhere to normal RFC3168 semantics. However, a sender may = chose not to implement the advanced compatibility mode - but such a TCP = sender could underestimate congestion volume (especially during heavy = congestion episodes) and then be throttled. Thus, there is a roadmap for incremental deployment of the accurate ecn = feedback (for TCP). Best regards, Richard Scheffenegger > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Mittwoch, 06. Juli 2011 21:17 > To: Scheffenegger, Richard; Mirja K=FChlewind; conex@ietf.org > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hi Richard, >=20 > Please see in line! >=20 >=20 > On 7/6/2011, "Scheffenegger, Richard" wrote: >=20 > > > >Hi Georgios, > > > >Thanks for the quick reply. > > > >I'm replying as the co-author of this draft. > > > >Your comment is only about one (of the three proposed) mechanisms to > signal more accurate ECN feedback. As you have noticed, we introduce > three different signaling encodings and semantics, each with = increasing > feature set (and accuracy) over the previous, but also with increasing > complexity at implementation. >=20 > Georgios: Yes, sorry for not mentioning them, I was referring to the > last > two solutions. >=20 > > > >Also note, that draft-kuehlewind-conex-accurate-ecn-00, even while > submitted in the ConEx WG, really has a broader scope, any deals with > the TCP layer alone. Conex is but one possible framework, where this > more accurate ECN feedback will be required. Submitting this draft to > TCPM was also shortly discussed internally, but ConEx really has a > current demand. Nevertheless, the broader scope (and different > constraints) of TCP should not get lost when discussing this draft. >=20 > Georgios: Okay, but my point regarding the fact that the the two = latter > proposed solutins biy your draft are complex to be deployed, is still > valid, since protocol changes need to be accomplished in order to > modify > the semantics of the TCP header, i.e., the semantics of the flags: NS, > CWR and ECE. >=20 > > > > > > > >Reading your draft, I fail to understand how this may work. Using > standard RFC3168 feedback, only a single (!) CE per RTT can be > signaled, and then TCP will always react with a single CC response per > RTT... regardless of how many CE marks the receiver actually received > during the RTT following the initial CE. >=20 > Georgios: Note that the solution uses the implementation specified in > RFC5348. According to this RFC5348, >=20 > "The receiver periodically sends feedback messages to the sender. > Feedback packets SHOULD normally be sent at least once per RTT, > unless the sender is sending at a rate of less than one packet per > RTT, in which case a feedback packet SHOULD be sent for every data > packet received. A feedback packet SHOULD also be sent whenever a > new loss event is detected without waiting for the end of an RTT, > and > whenever an out-of-order data packet is received that removes a = loss > event from the history. >=20 > If the sender is transmitting at a high rate (many packets per = RTT), > there may be some advantages to sending periodic feedback messages > more than once per RTT as this allows faster response to changing > RTT > measurements and more resilience to feedback packet loss." >=20 > > > >Calculating the sending rate at the sender doesn't seem to accomplish > what you aim at (or the ingenious idea is missing in that draft). With > the widespread adoption of TCP SACK, and alternate congestion > controller responses than NewReno (e.g. CUBIC, Compound, ...), the > closed formula you quote is only a crude guess at the actual sending > rate. These newer TCP congestion control reactions will conform to = that > formula only under certain (limited) circumstances, at best. (The > formula gives a worst case estimate, but the typical sending rate will > be higher). Furthermore, the goal of ECN is, to avoid loss (denoted = "p" > in the formula) due to congestion as much as possible. Because of the > limited signal bandwidth (one bit per RTT) of RFC3168, compared to > congestion loss (one bit per segment sent - conveyed more or less > accurately by ACKs/SACKs), putting standard ECN feedback into "p" will > not work. >=20 > Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control = (TFRC)) > is used by this solution. So the accuracy of the congestion rate > calculation will depend on the accuracy of the TFRC. Moreover, > according > to RFC5348: > "The throughput equation currently REQUIRED for TFRC is a slightly > simplified version of the throughput equation for Reno TCP from > [PFTK98]. Ideally, we would prefer a throughput equation based on > selective acknowledgment (SACK) TCP, but no one has yet derived the > throughput equation for SACK TCP, and simulations and experiments > suggest that the differences between the two equations would be > relatively minor [FF99] (Appendix B).", from [RFC5348] >=20 > Furthermore, note that p is the rate of loss events and is depending = on > the loss rate. Loss rate measurement is performed at the receiver, > based > on the detection of lost or marked packets from the sequence numbers = of > arriving packets. >=20 > p can be send from receiver towards the sender in feedback packets. > In TFRC several feedback packets can be sent towards the sender within > one RTT, depending on the sender data rate. >=20 >=20 >=20 > > > > > >Furthermore, the congestion volume, if I followed ConEx correctly, is > the volume of bytes (measured as IP-layer bytes, NOT IP payload, or = TCP > payload bytes) which were received with CE set. With only a single bit > of feedback per RTT, the congestion volume therefore has a lower bound > of PMTU bytes per RTT (actually, the minimum packet size possible, = when > 1-byte TCP payload segments are sent for whatever reason), and an = upper > bound of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP > Options])+FlightSize. > > > >Your formula would, as it seems to me, always estimate the congestion > volume to be close to cwnd/2 (excluding the IP Header, TCP Headers, = and > also excluding the actual number of congestions during that RTT). This > may be a (very) conservative estimate during low congestion periods, > but a very aggressive (=3Dmuch too small) estimate during heavy > congestion periods (e.g. 1 RTT, where each segment is CE marked). >=20 > Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control = (TFRC)) > is used by this solution. So the accuracy of the congestion rate > calculation will depend on the accuracy of the TFRC. >=20 >=20 > > > > > > > >Again, the goal for Accurate ECN feedback is to allow an exact (under > common circumstances) feedback of the CE marks as seen by a TCP > receiver, to be sent back to the sender. As TCP can not rely on > external means to enforce honesty (Conex would be one such external > means), ECN Nonce support would be beneficial. >=20 > Georgios: Yes I agree it might be beneficial. >=20 >=20 > > > > > >One more word w.r.t. complexity: I believe that the gap between > network performance and CPU performance will not shrink in the future. > All developments over the last decade points to an ever widening gap. > Therefore, schemes which couldn't be hoped to have any chance to be > implemented, because of their complexity, such as Conex, are today > running at wirespeed in 10G environments. The times, where one major > design goal of a protocol was to use as few as possible machine > instructions to encode/decode and interpret, are long past. > > > >I have seen early SACK and TS work was discussed in terms of number = of > machine instructions added to the TCP codepath (which is one piece of > the puzzle to understand why timestamp semantics are defined the way > they are). > > > >(Also, calculating the integer square root is more involved than = doing > some bit-banging ;) >=20 > Georgios: I think that you refer to my statement regarding > implementation > complexity of the Re-ECN solution. The term that I have used is not = the > correct one. I should have used deployment complexity instead of > implmentation complexity. >=20 > Best regards, > Georgios >=20 >=20 > > > > > >Richard Scheffenegger > > > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: Mittwoch, 06. Juli 2011 14:27 > >> To: 'Mirja K=FChlewind'; conex@ietf.org > >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > >> > >> Hi Mirja > >> > >> I have (quickly) read the document = draft-kuehlewind-conex-accurate- > >> ecn-00. > >> So sorry if I have not understood the concept well! > >> > >> The described solution in this draft is based on [draft-briscoe- > >> tsvwg-re-ecn-tcp-09] and is actually used to > >> carry the required feedback from the receiver to the sender such > that > >> the > >> sender could calculate > >> the experienced congestion rate (from sender to receiver). > >> > >> In my opinion this solution being similar to the one proposed in > >> [draft-briscoe- tsvwg-re-ecn-tcp-09] > >> seems to be quite complex to be deployed, since protocol changes > need > >> to be > >> accomplished in order to modify the > >> semantics of the TCP header, i.e., the semantics of the flags: NS, > CWR > >> and > >> ECE. > >> > >> In > >> http://www.ietf.org/id/draft-karagiannis-conex-congestion- > calculation- > >> 00.txt > >> another solution on > >> calculating the congestion rate at the sender is described where > >> these > >> changes in the semantics of > >> TCP are not required. > >> > >> This document provides a solution to this problem as follows, see > >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt > >> > >> When the sender needs to reduce its sending rate, then the sender > can > >> calculate the exposed CONGESTION RATE by subtracting the TCP > >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) > >> from the TCP throughput calculated at the same sender side during > the > >> previous RTT, i.e., (RTTi-1), where i is an integer equal or = higher > >> than 1. > >> > >> The TCP throughput at the sender side can be calculated using, = e.g., > >> the following equation specified in [RFC5348]: > >> > >> > >> "The throughput equation for X_Bps, TCP's average sending rate = in > >> bytes per second, is: > >> > >> s > >> X_Bps =3D = --------------------------------------------------------- > - > >> R*sqrt(2*b*p/3) + (t_RTO * > (3*sqrt(3*b*p/8)*p*(1+32*p^2))) > >> > >> Where: > >> > >> X_Bps is TCP's average transmit rate in bytes per second. > (X_Bps > >> is the same as X_calc in RFC 3448.) > >> > >> s is the segment size in bytes (excluding IP and transport > >> protocol headers). > >> > >> R is the round-trip time in seconds. > >> > >> p is the loss event rate, between 0 and 1.0, of the number of > >> loss > >> events as a fraction of the number of packets transmitted. > >> > >> t_RTO is the TCP retransmission timeout value in seconds. > >> > >> b is the maximum number of packets acknowledged by a single > TCP > >> acknowledgement.", copied from [RFC5368]. > >> > >> > >> Note that the transport path throughput calculated at the sender is > >> defined > >> as: The per flow transport sending rate as a function of the > congestion > >> rate, round-trip time, and segment size. The transport path > throughput > >> calculated at the sender using the TCP throughput equation = specified > in > >> [RFC5348]. Note that in [RFC5348] the term congestion rate is > denoted > >> as > >> loss event rate. According to [RFC5348] a loss event is defined as > one > >> or > >> more lost or marked packets from a window of data, where a marked > >> packet > >> refers to a congestion indication (CE) from Explicit Congestion > >> Notification > >> (ECN) [RFC3168]; > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > -----Original Message----- > >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > >> Behalf > >> > Of Mirja K=FChlewind > >> > Sent: woensdag 6 juli 2011 10:23 > >> > To: conex@ietf.org > >> > Subject: [conex] New draft(s) on TCP modifications for ConEx > >> > > >> > Hello, > >> > > >> > we submitted two new drafts regarding the needed TCP = modifications > >> for > >> > ConEx. > >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback > >> (more > >> than > >> > max. one signal per RTT) is needed. The same information would be > >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. > >> This is > >> > why, we decided to split this modification into a separate and > tried > >> to > >> specify > >> > this independent of ConEx. Thus we have two drafts now: > >> > > >> > 1. draft-kuehlewind-conex-accurate-ecn > >> > This draft currently proposes three different coding scheme to > >> realize a > >> more > >> > accurate ECN feedback. All approaches use the available 'classic' > ECN > >> bit > >> > space as only one mechanism (classic ECN or the new more accurate > >> scheme) > >> > is needed at a time. The goal is to chose one of the coding > options > >> and > >> have > >> > the other option and all discussions removed at later version of > this > >> draft. > >> > > >> > 2. draft-kuehlewind-conex-tcp-modifications > >> > This draft describes all other modifications/recommendations to > use > >> ConEx > >> > with TCP. This is the use of ECN and SACK and recommendations on > the > >> > credit bit. > >> > This document contains several points which need further > discussion > >> e.g. > >> the > >> > handling and validity of credits. > >> > > >> > Please have a look at the drafts; Feedback is very welcome! > >> > > >> > Mirja and Richard > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Wed Jul 6 13:25: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 C020C21F8BB0 for ; Wed, 6 Jul 2011 13:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 RPb25LP0yHch for ; Wed, 6 Jul 2011 13:25:51 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9021F8B6F for ; Wed, 6 Jul 2011 13:25:50 -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); Wed, 6 Jul 2011 21:25:49 +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); Wed, 6 Jul 2011 21:25:49 +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 1309983948390; Wed, 6 Jul 2011 21:25:48 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.64.12]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p66KPjiT022528; Wed, 6 Jul 2011 21:25:45 +0100 Message-Id: <201107062025.p66KPjiT022528@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jul 2011 21:25:46 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: References: <5FDC413D5FA246468C200652D63E627A0F1E306B@LDCMVEXC1-PRD.hq.netapp.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: 06 Jul 2011 20:25:49.0555 (UTC) FILETIME=[E4FDB430:01CC3C1A] Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 20:25:52 -0000 Georgios, The dependency goes like this: 1. Actual-Congestion-rate 2. -> Receiver's-Measured-Congestion-rate 3. -> Feedback-to-sender 4. -> Sender's-Measured-Congestion-rate 5. -> TCP-algo 6. -> TCP-bit-rate Information is lost between stages 2-4 because of=20 the way TCP feedback works in the case of ECN. So=20 (1) =3D (2) <=3D (3) <=3D (4), where <=3D means less than or equal to. The TCP equation is derived by setting the=20 Sender's-Measured-Congestion-rate (stage 4) to p,=20 running p through a mathematical model of the=20 TCP-algo (stage 5) to derive the TCP-bit-rate (stage 6). If the sender derives p from its TCP-bit-rate, by=20 reversing the theoretical equation, it will get=20 metric (4). Unsurprisingly, it will get the=20 Congestion-rate that it has been responding to with the TCP algo. It won't get back any further to metrics 1-3. So=20 the approach in your I-D achieves precisely nothing. Another point: You're confusing complexity with difficulty. It might be difficult to change the semantics of=20 fields in the TCP header (because we have to=20 persuade all sorts of strange people at the IETF=20 ;) But the algorithm to run is not complex -=20 receiver adds to a counter, sends the counter in=20 a field, sender reads counter, does a subtract=20 and shift or two and we're done. There are two=20 implementations, and there are a lot more complicated things in TCP than= this. The really difficult bit of standardisation is=20 largely done: we are chartered to produce an=20 experimental standard. Importantly, we have one=20 good way to negotiate that the new semantics are=20 being used, which is essential for backwards=20 compatibility. I think Richard & Mirja are right=20 to suggest alternatives for the last stage -=20 actually doing the feedback. Because reliability=20 is quite tough for this - it's OK most of the=20 time, but we don't know how prevalent the corner-cases are. Finally, if you want something complex (and=20 difficult), try implementing an algorithm to=20 derive p from X in the rate equation in your I-D. I think you're I-D just shows you've allowed=20 yourself to get in a muddle over what depends on what. Bob At 20:17 06/07/2011, Georgios Karagiannis wrote: >Hi Richard, > >Please see in line! > > >On 7/6/2011, "Scheffenegger, Richard" wrote: > > > > >Hi Georgios, > > > >Thanks for the quick reply. > > > >I'm replying as the co-author of this draft. > > > >Your comment is only about one (of the three=20 > proposed) mechanisms to signal more accurate=20 > ECN feedback. As you have noticed, we introduce=20 > three different signaling encodings and=20 > semantics, each with increasing feature set=20 > (and accuracy) over the previous, but also with=20 > increasing complexity at implementation. > >Georgios: Yes, sorry for not mentioning them, I was referring to the last >two solutions. > > > > >Also note, that=20 > draft-kuehlewind-conex-accurate-ecn-00, even=20 > while submitted in the ConEx WG, really has a=20 > broader scope, any deals with the TCP layer=20 > alone. Conex is but one possible framework,=20 > where this more accurate ECN feedback will be=20 > required. Submitting this draft to TCPM was=20 > also shortly discussed internally, but ConEx=20 > really has a current demand. Nevertheless, the=20 > broader scope (and different constraints) of=20 > TCP should not get lost when discussing this draft. > >Georgios: Okay, but my point regarding the fact that the the two latter >proposed solutins biy your draft are complex to be deployed, is still >valid, since protocol changes need to be accomplished in order to modify >the semantics of the TCP header, i.e., the semantics of the flags: NS, >CWR and ECE. > > > > > > > > >Reading your draft, I fail to understand how=20 > this may work. Using standard RFC3168 feedback,=20 > only a single (!) CE per RTT can be signaled,=20 > and then TCP will always react with a single CC=20 > response per RTT... regardless of how many CE=20 > marks the receiver actually received during the RTT following the initial= CE. > >Georgios: Note that the solution uses the implementation specified in >RFC5348. According to this RFC5348, > >"The receiver periodically sends feedback messages to the sender. > Feedback packets SHOULD normally be sent at least once per RTT, > unless the sender is sending at a rate of less than one packet per > RTT, in which case a feedback packet SHOULD be sent for every data > packet received. A feedback packet SHOULD also be sent whenever a > new loss event is detected without waiting for the end of an RTT, and > whenever an out-of-order data packet is received that removes a loss > event from the history. > > If the sender is transmitting at a high rate (many packets per RTT), > there may be some advantages to sending periodic feedback messages > more than once per RTT as this allows faster response to changing RTT > measurements and more resilience to feedback packet loss." > > > > >Calculating the sending rate at the sender=20 > doesn't seem to accomplish what you aim at (or=20 > the ingenious idea is missing in that draft).=20 > With the widespread adoption of TCP SACK, and=20 > alternate congestion controller responses than=20 > NewReno (e.g. CUBIC, Compound, ...), the closed=20 > formula you quote is only a crude guess at the=20 > actual sending rate. These newer TCP congestion=20 > control reactions will conform to that formula=20 > only under certain (limited) circumstances, at=20 > best. (The formula gives a worst case estimate,=20 > but the typical sending rate will be higher).=20 > Furthermore, the goal of ECN is, to avoid loss=20 > (denoted "p" in the formula) due to congestion=20 > as much as possible. Because of the limited=20 > signal bandwidth (one bit per RTT) of RFC3168,=20 > compared to congestion loss (one bit per=20 > segment sent - conveyed more or less accurately=20 > by ACKs/SACKs), putting standard ECN feedback into "p" will not work. > >Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >is used by this solution. So the accuracy of the congestion rate >calculation will depend on the accuracy of the TFRC. Moreover, according >to RFC5348: > "The throughput equation currently REQUIRED for TFRC is a slightly > simplified version of the throughput equation for Reno TCP from > [PFTK98]. Ideally, we would prefer a throughput equation based on > selective acknowledgment (SACK) TCP, but no one has yet derived the > throughput equation for SACK TCP, and simulations and experiments > suggest that the differences between the two equations would be > relatively minor [FF99] (Appendix B).", from [RFC5348] > >Furthermore, note that p is the rate of loss events and is depending on >the loss rate. Loss rate measurement is performed at the receiver, based >on the detection of lost or marked packets from the sequence numbers of >arriving packets. > >p can be send from receiver towards the sender in feedback packets. >In TFRC several feedback packets can be sent towards the sender within >one RTT, depending on the sender data rate. > > > > > > > > >Furthermore, the congestion volume, if I=20 > followed ConEx correctly, is the volume of=20 > bytes (measured as IP-layer bytes, NOT IP=20 > payload, or TCP payload bytes) which were=20 > received with CE set. With only a single bit of=20 > feedback per RTT, the congestion volume=20 > therefore has a lower bound of PMTU bytes per=20 > RTT (actually, the minimum packet size=20 > possible, when 1-byte TCP payload segments are=20 > sent for whatever reason), and an upper bound=20 > of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP Options])+FlightSize. > > > >Your formula would, as it seems to me, always=20 > estimate the congestion volume to be close to=20 > cwnd/2 (excluding the IP Header, TCP Headers,=20 > and also excluding the actual number of=20 > congestions during that RTT). This may be a=20 > (very) conservative estimate during low=20 > congestion periods, but a very aggressive=20 > (=3Dmuch too small) estimate during heavy=20 > congestion periods (e.g. 1 RTT, where each segment is CE marked). > >Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >is used by this solution. So the accuracy of the congestion rate >calculation will depend on the accuracy of the TFRC. > > > > > > > > > >Again, the goal for Accurate ECN feedback is=20 > to allow an exact (under common circumstances)=20 > feedback of the CE marks as seen by a TCP=20 > receiver, to be sent back to the sender. As TCP=20 > can not rely on external means to enforce=20 > honesty (Conex would be one such external=20 > means), ECN Nonce support would be beneficial. > >Georgios: Yes I agree it might be beneficial. > > > > > > > >One more word w.r.t. complexity: I believe=20 > that the gap between network performance and=20 > CPU performance will not shrink in the future.=20 > All developments over the last decade points to=20 > an ever widening gap. Therefore, schemes which=20 > couldn't be hoped to have any chance to be=20 > implemented, because of their complexity, such=20 > as Conex, are today running at wirespeed in 10G=20 > environments. The times, where one major design=20 > goal of a protocol was to use as few as=20 > possible machine instructions to encode/decode and interpret, are long= past. > > > >I have seen early SACK and TS work was=20 > discussed in terms of number of machine=20 > instructions added to the TCP codepath (which=20 > is one piece of the puzzle to understand why=20 > timestamp semantics are defined the way they are). > > > >(Also, calculating the integer square root is=20 > more involved than doing some bit-banging ;) > >Georgios: I think that you refer to my statement regarding implementation >complexity of the Re-ECN solution. The term that I have used is not the >correct one. I should have used deployment complexity instead of >implmentation complexity. > >Best regards, >Georgios > > > > > > > >Richard Scheffenegger > > > >> -----Original Message----- > >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> Sent: Mittwoch, 06. Juli 2011 14:27 > >> To: 'Mirja K=FChlewind'; conex@ietf.org > >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > >> > >> Hi Mirja > >> > >> I have (quickly) read the document draft-kuehlewind-conex-accurate- > >> ecn-00. > >> So sorry if I have not understood the concept well! > >> > >> The described solution in this draft is based on [draft-briscoe- > >> tsvwg-re-ecn-tcp-09] and is actually used to > >> carry the required feedback from the receiver to the sender such that > >> the > >> sender could calculate > >> the experienced congestion rate (from sender to receiver). > >> > >> In my opinion this solution being similar to the one proposed in > >> [draft-briscoe- tsvwg-re-ecn-tcp-09] > >> seems to be quite complex to be deployed, since protocol changes need > >> to be > >> accomplished in order to modify the > >> semantics of the TCP header, i.e., the semantics of the flags: NS, CWR > >> and > >> ECE. > >> > >> In > >> http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation- > >> 00.txt > >> another solution on > >> calculating the congestion rate at the sender is described where > >> these > >> changes in the semantics of > >> TCP are not required. > >> > >> This document provides a solution to this problem as follows, see > >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt > >> > >> When the sender needs to reduce its sending rate, then the sender can > >> calculate the exposed CONGESTION RATE by subtracting the TCP > >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) > >> from the TCP throughput calculated at the same sender side during the > >> previous RTT, i.e., (RTTi-1), where i is an integer equal or higher > >> than 1. > >> > >> The TCP throughput at the sender side can be calculated using, e.g., > >> the following equation specified in [RFC5348]: > >> > >> > >> "The throughput equation for X_Bps, TCP's average sending rate in > >> bytes per second, is: > >> > >> s > >> X_Bps =3D ---------------------------------------------------------- > >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))) > >> > >> Where: > >> > >> X_Bps is TCP's average transmit rate in bytes per second. (X_Bps > >> is the same as X_calc in RFC 3448.) > >> > >> s is the segment size in bytes (excluding IP and transport > >> protocol headers). > >> > >> R is the round-trip time in seconds. > >> > >> p is the loss event rate, between 0 and 1.0, of the number of > >> loss > >> events as a fraction of the number of packets transmitted. > >> > >> t_RTO is the TCP retransmission timeout value in seconds. > >> > >> b is the maximum number of packets acknowledged by a single TCP > >> acknowledgement.", copied from [RFC5368]. > >> > >> > >> Note that the transport path throughput calculated at the sender is > >> defined > >> as: The per flow transport sending rate as a function of the congestion > >> rate, round-trip time, and segment size. The transport path throughput > >> calculated at the sender using the TCP throughput equation specified in > >> [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted > >> as > >> loss event rate. According to [RFC5348] a loss event is defined as one > >> or > >> more lost or marked packets from a window of data, where a marked > >> packet > >> refers to a congestion indication (CE) from Explicit Congestion > >> Notification > >> (ECN) [RFC3168]; > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > -----Original Message----- > >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > >> Behalf > >> > Of Mirja K=FChlewind > >> > Sent: woensdag 6 juli 2011 10:23 > >> > To: conex@ietf.org > >> > Subject: [conex] New draft(s) on TCP modifications for ConEx > >> > > >> > Hello, > >> > > >> > we submitted two new drafts regarding the needed TCP modifications > >> for > >> > ConEx. > >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback > >> (more > >> than > >> > max. one signal per RTT) is needed. The same information would be > >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. > >> This is > >> > why, we decided to split this modification into a separate and tried > >> to > >> specify > >> > this independent of ConEx. Thus we have two drafts now: > >> > > >> > 1. draft-kuehlewind-conex-accurate-ecn > >> > This draft currently proposes three different coding scheme to > >> realize a > >> more > >> > accurate ECN feedback. All approaches use the available 'classic' ECN > >> bit > >> > space as only one mechanism (classic ECN or the new more accurate > >> scheme) > >> > is needed at a time. The goal is to chose one of the coding options > >> and > >> have > >> > the other option and all discussions removed at later version of this > >> draft. > >> > > >> > 2. draft-kuehlewind-conex-tcp-modifications > >> > This draft describes all other modifications/recommendations to use > >> ConEx > >> > with TCP. This is the use of ECN and SACK and recommendations on the > >> > credit bit. > >> > This document contains several points which need further discussion > >> e.g. > >> the > >> > handling and validity of credits. > >> > > >> > Please have a look at the drafts; Feedback is very welcome! > >> > > >> > Mirja and Richard > >> > >> _______________________________________________ > >> 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=20 From karagian@cs.utwente.nl Wed Jul 6 14:06:37 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 4F56221F8840 for ; Wed, 6 Jul 2011 14:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=0.008, 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 XCSt7y6x8NUN for ; Wed, 6 Jul 2011 14:06:36 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id CCE9E21F87EF for ; Wed, 6 Jul 2011 14:06:35 -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 p66L4vIa026218; Wed, 6 Jul 2011 23:04:57 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Jul 2011 21:06:37 +0000 To: "Bob Briscoe" Date: Wed, 06 Jul 2011 21:06:36 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107062025.p66KPjiT022528@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]); Wed, 06 Jul 2011 23:05:08 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 21:06:37 -0000 Hi Bob, The I-D uses the RFC5348 (TCP Friendly Rate Control (TFRC)). So the accuracy of the congestion rate calculation will depend on the accuracy of TFRC, see also my previous email. Best regards, Georgios On 7/6/2011, "Bob Briscoe" wrote: >Georgios, > >The dependency goes like this: > >1. Actual-Congestion-rate >2. -> Receiver's-Measured-Congestion-rate >3. -> Feedback-to-sender >4. -> Sender's-Measured-Congestion-rate >5. -> TCP-algo >6. -> TCP-bit-rate > >Information is lost between stages 2-4 because of=20 >the way TCP feedback works in the case of ECN. So=20 >(1) =3D (2) <=3D (3) <=3D (4), where <=3D means less than or equal to. > >The TCP equation is derived by setting the=20 >Sender's-Measured-Congestion-rate (stage 4) to p,=20 >running p through a mathematical model of the=20 >TCP-algo (stage 5) to derive the TCP-bit-rate (stage 6). > >If the sender derives p from its TCP-bit-rate, by=20 >reversing the theoretical equation, it will get=20 >metric (4). Unsurprisingly, it will get the=20 >Congestion-rate that it has been responding to with the TCP algo. > >It won't get back any further to metrics 1-3. So=20 >the approach in your I-D achieves precisely nothing. > >Another point: You're confusing complexity with difficulty. > >It might be difficult to change the semantics of=20 >fields in the TCP header (because we have to=20 >persuade all sorts of strange people at the IETF=20 >;) But the algorithm to run is not complex -=20 >receiver adds to a counter, sends the counter in=20 >a field, sender reads counter, does a subtract=20 >and shift or two and we're done. There are two=20 >implementations, and there are a lot more complicated things in TCP than thi= s. > >The really difficult bit of standardisation is=20 >largely done: we are chartered to produce an=20 >experimental standard. Importantly, we have one=20 >good way to negotiate that the new semantics are=20 >being used, which is essential for backwards=20 >compatibility. I think Richard & Mirja are right=20 >to suggest alternatives for the last stage -=20 >actually doing the feedback. Because reliability=20 >is quite tough for this - it's OK most of the=20 >time, but we don't know how prevalent the corner-cases are. > >Finally, if you want something complex (and=20 >difficult), try implementing an algorithm to=20 >derive p from X in the rate equation in your I-D. > >I think you're I-D just shows you've allowed=20 >yourself to get in a muddle over what depends on what. > > > >Bob > > >At 20:17 06/07/2011, Georgios Karagiannis wrote: >>Hi Richard, >> >>Please see in line! >> >> >>On 7/6/2011, "Scheffenegger, Richard" wrote: >> >> > >> >Hi Georgios, >> > >> >Thanks for the quick reply. >> > >> >I'm replying as the co-author of this draft. >> > >> >Your comment is only about one (of the three=20 >> proposed) mechanisms to signal more accurate=20 >> ECN feedback. As you have noticed, we introduce=20 >> three different signaling encodings and=20 >> semantics, each with increasing feature set=20 >> (and accuracy) over the previous, but also with=20 >> increasing complexity at implementation. >> >>Georgios: Yes, sorry for not mentioning them, I was referring to the last >>two solutions. >> >> > >> >Also note, that=20 >> draft-kuehlewind-conex-accurate-ecn-00, even=20 >> while submitted in the ConEx WG, really has a=20 >> broader scope, any deals with the TCP layer=20 >> alone. Conex is but one possible framework,=20 >> where this more accurate ECN feedback will be=20 >> required. Submitting this draft to TCPM was=20 >> also shortly discussed internally, but ConEx=20 >> really has a current demand. Nevertheless, the=20 >> broader scope (and different constraints) of=20 >> TCP should not get lost when discussing this draft. >> >>Georgios: Okay, but my point regarding the fact that the the two latter >>proposed solutins biy your draft are complex to be deployed, is still >>valid, since protocol changes need to be accomplished in order to modify >>the semantics of the TCP header, i.e., the semantics of the flags: NS, >>CWR and ECE. >> >> > >> > >> > >> >Reading your draft, I fail to understand how=20 >> this may work. Using standard RFC3168 feedback,=20 >> only a single (!) CE per RTT can be signaled,=20 >> and then TCP will always react with a single CC=20 >> response per RTT... regardless of how many CE=20 >> marks the receiver actually received during the RTT following the initial = CE. >> >>Georgios: Note that the solution uses the implementation specified in >>RFC5348. According to this RFC5348, >> >>"The receiver periodically sends feedback messages to the sender. >> Feedback packets SHOULD normally be sent at least once per RTT, >> unless the sender is sending at a rate of less than one packet per >> RTT, in which case a feedback packet SHOULD be sent for every data >> packet received. A feedback packet SHOULD also be sent whenever a >> new loss event is detected without waiting for the end of an RTT, and >> whenever an out-of-order data packet is received that removes a loss >> event from the history. >> >> If the sender is transmitting at a high rate (many packets per RTT), >> there may be some advantages to sending periodic feedback messages >> more than once per RTT as this allows faster response to changing RTT >> measurements and more resilience to feedback packet loss." >> >> > >> >Calculating the sending rate at the sender=20 >> doesn't seem to accomplish what you aim at (or=20 >> the ingenious idea is missing in that draft).=20 >> With the widespread adoption of TCP SACK, and=20 >> alternate congestion controller responses than=20 >> NewReno (e.g. CUBIC, Compound, ...), the closed=20 >> formula you quote is only a crude guess at the=20 >> actual sending rate. These newer TCP congestion=20 >> control reactions will conform to that formula=20 >> only under certain (limited) circumstances, at=20 >> best. (The formula gives a worst case estimate,=20 >> but the typical sending rate will be higher).=20 >> Furthermore, the goal of ECN is, to avoid loss=20 >> (denoted "p" in the formula) due to congestion=20 >> as much as possible. Because of the limited=20 >> signal bandwidth (one bit per RTT) of RFC3168,=20 >> compared to congestion loss (one bit per=20 >> segment sent - conveyed more or less accurately=20 >> by ACKs/SACKs), putting standard ECN feedback into "p" will not work. >> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >>is used by this solution. So the accuracy of the congestion rate >>calculation will depend on the accuracy of the TFRC. Moreover, according >>to RFC5348: >> "The throughput equation currently REQUIRED for TFRC is a slightly >> simplified version of the throughput equation for Reno TCP from >> [PFTK98]. Ideally, we would prefer a throughput equation based on >> selective acknowledgment (SACK) TCP, but no one has yet derived the >> throughput equation for SACK TCP, and simulations and experiments >> suggest that the differences between the two equations would be >> relatively minor [FF99] (Appendix B).", from [RFC5348] >> >>Furthermore, note that p is the rate of loss events and is depending on >>the loss rate. Loss rate measurement is performed at the receiver, based >>on the detection of lost or marked packets from the sequence numbers of >>arriving packets. >> >>p can be send from receiver towards the sender in feedback packets. >>In TFRC several feedback packets can be sent towards the sender within >>one RTT, depending on the sender data rate. >> >> >> >> > >> > >> >Furthermore, the congestion volume, if I=20 >> followed ConEx correctly, is the volume of=20 >> bytes (measured as IP-layer bytes, NOT IP=20 >> payload, or TCP payload bytes) which were=20 >> received with CE set. With only a single bit of=20 >> feedback per RTT, the congestion volume=20 >> therefore has a lower bound of PMTU bytes per=20 >> RTT (actually, the minimum packet size=20 >> possible, when 1-byte TCP payload segments are=20 >> sent for whatever reason), and an upper bound=20 >> of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP Options])+FlightSize. >> > >> >Your formula would, as it seems to me, always=20 >> estimate the congestion volume to be close to=20 >> cwnd/2 (excluding the IP Header, TCP Headers,=20 >> and also excluding the actual number of=20 >> congestions during that RTT). This may be a=20 >> (very) conservative estimate during low=20 >> congestion periods, but a very aggressive=20 >> (=3Dmuch too small) estimate during heavy=20 >> congestion periods (e.g. 1 RTT, where each segment is CE marked). >> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >>is used by this solution. So the accuracy of the congestion rate >>calculation will depend on the accuracy of the TFRC. >> >> >> > >> > >> > >> >Again, the goal for Accurate ECN feedback is=20 >> to allow an exact (under common circumstances)=20 >> feedback of the CE marks as seen by a TCP=20 >> receiver, to be sent back to the sender. As TCP=20 >> can not rely on external means to enforce=20 >> honesty (Conex would be one such external=20 >> means), ECN Nonce support would be beneficial. >> >>Georgios: Yes I agree it might be beneficial. >> >> >> > >> > >> >One more word w.r.t. complexity: I believe=20 >> that the gap between network performance and=20 >> CPU performance will not shrink in the future.=20 >> All developments over the last decade points to=20 >> an ever widening gap. Therefore, schemes which=20 >> couldn't be hoped to have any chance to be=20 >> implemented, because of their complexity, such=20 >> as Conex, are today running at wirespeed in 10G=20 >> environments. The times, where one major design=20 >> goal of a protocol was to use as few as=20 >> possible machine instructions to encode/decode and interpret, are long pas= t. >> > >> >I have seen early SACK and TS work was=20 >> discussed in terms of number of machine=20 >> instructions added to the TCP codepath (which=20 >> is one piece of the puzzle to understand why=20 >> timestamp semantics are defined the way they are). >> > >> >(Also, calculating the integer square root is=20 >> more involved than doing some bit-banging ;) >> >>Georgios: I think that you refer to my statement regarding implementation >>complexity of the Re-ECN solution. The term that I have used is not the >>correct one. I should have used deployment complexity instead of >>implmentation complexity. >> >>Best regards, >>Georgios >> >> >> > >> > >> >Richard Scheffenegger >> > >> >> -----Original Message----- >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> Sent: Mittwoch, 06. Juli 2011 14:27 >> >> To: 'Mirja K=FChlewind'; conex@ietf.org >> >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >> >> >> >> Hi Mirja >> >> >> >> I have (quickly) read the document draft-kuehlewind-conex-accurate- >> >> ecn-00. >> >> So sorry if I have not understood the concept well! >> >> >> >> The described solution in this draft is based on [draft-briscoe- >> >> tsvwg-re-ecn-tcp-09] and is actually used to >> >> carry the required feedback from the receiver to the sender such that >> >> the >> >> sender could calculate >> >> the experienced congestion rate (from sender to receiver). >> >> >> >> In my opinion this solution being similar to the one proposed in >> >> [draft-briscoe- tsvwg-re-ecn-tcp-09] >> >> seems to be quite complex to be deployed, since protocol changes need >> >> to be >> >> accomplished in order to modify the >> >> semantics of the TCP header, i.e., the semantics of the flags: NS, CWR >> >> and >> >> ECE. >> >> >> >> In >> >> http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation- >> >> 00.txt >> >> another solution on >> >> calculating the congestion rate at the sender is described where >> >> these >> >> changes in the semantics of >> >> TCP are not required. >> >> >> >> This document provides a solution to this problem as follows, see >> >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt >> >> >> >> When the sender needs to reduce its sending rate, then the sender can >> >> calculate the exposed CONGESTION RATE by subtracting the TCP >> >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) >> >> from the TCP throughput calculated at the same sender side during the >> >> previous RTT, i.e., (RTTi-1), where i is an integer equal or higher >> >> than 1. >> >> >> >> The TCP throughput at the sender side can be calculated using, e.g., >> >> the following equation specified in [RFC5348]: >> >> >> >> >> >> "The throughput equation for X_Bps, TCP's average sending rate in >> >> bytes per second, is: >> >> >> >> s >> >> X_Bps =3D ---------------------------------------------------------- >> >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))) >> >> >> >> Where: >> >> >> >> X_Bps is TCP's average transmit rate in bytes per second. (X_Bps >> >> is the same as X_calc in RFC 3448.) >> >> >> >> s is the segment size in bytes (excluding IP and transport >> >> protocol headers). >> >> >> >> R is the round-trip time in seconds. >> >> >> >> p is the loss event rate, between 0 and 1.0, of the number of >> >> loss >> >> events as a fraction of the number of packets transmitted. >> >> >> >> t_RTO is the TCP retransmission timeout value in seconds. >> >> >> >> b is the maximum number of packets acknowledged by a single TCP >> >> acknowledgement.", copied from [RFC5368]. >> >> >> >> >> >> Note that the transport path throughput calculated at the sender is >> >> defined >> >> as: The per flow transport sending rate as a function of the congestion >> >> rate, round-trip time, and segment size. The transport path throughput >> >> calculated at the sender using the TCP throughput equation specified in >> >> [RFC5348]. Note that in [RFC5348] the term congestion rate is denoted >> >> as >> >> loss event rate. According to [RFC5348] a loss event is defined as one >> >> or >> >> more lost or marked packets from a window of data, where a marked >> >> packet >> >> refers to a congestion indication (CE) from Explicit Congestion >> >> Notification >> >> (ECN) [RFC3168]; >> >> >> >> Best regards, >> >> Georgios >> >> >> >> >> >> >> >> > -----Original Message----- >> >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> >> Behalf >> >> > Of Mirja K=FChlewind >> >> > Sent: woensdag 6 juli 2011 10:23 >> >> > To: conex@ietf.org >> >> > Subject: [conex] New draft(s) on TCP modifications for ConEx >> >> > >> >> > Hello, >> >> > >> >> > we submitted two new drafts regarding the needed TCP modifications >> >> for >> >> > ConEx. >> >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback >> >> (more >> >> than >> >> > max. one signal per RTT) is needed. The same information would be >> >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. >> >> This is >> >> > why, we decided to split this modification into a separate and tried >> >> to >> >> specify >> >> > this independent of ConEx. Thus we have two drafts now: >> >> > >> >> > 1. draft-kuehlewind-conex-accurate-ecn >> >> > This draft currently proposes three different coding scheme to >> >> realize a >> >> more >> >> > accurate ECN feedback. All approaches use the available 'classic' ECN >> >> bit >> >> > space as only one mechanism (classic ECN or the new more accurate >> >> scheme) >> >> > is needed at a time. The goal is to chose one of the coding options >> >> and >> >> have >> >> > the other option and all discussions removed at later version of this >> >> draft. >> >> > >> >> > 2. draft-kuehlewind-conex-tcp-modifications >> >> > This draft describes all other modifications/recommendations to use >> >> ConEx >> >> > with TCP. This is the use of ECN and SACK and recommendations on the >> >> > credit bit. >> >> > This document contains several points which need further discussion >> >> e.g. >> >> the >> >> > handling and validity of credits. >> >> > >> >> > Please have a look at the drafts; Feedback is very welcome! >> >> > >> >> > Mirja and Richard >> >> >> >> _______________________________________________ >> >> 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=20 From michawe@ifi.uio.no Wed Jul 6 14:11: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 4363A21F89C5 for ; Wed, 6 Jul 2011 14:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY8czMH35DI5 for ; Wed, 6 Jul 2011 14:11:37 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE3621F89BD for ; Wed, 6 Jul 2011 14:11:34 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1QeZNU-0004FE-Th; Wed, 06 Jul 2011 23:11:24 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1QeZNU-0001dI-Hx; Wed, 06 Jul 2011 23:11:24 +0200 Message-Id: <9A8639FE-FB22-422F-816D-613EE7DBB44E@ifi.uio.no> From: Michael Welzl To: Bob Briscoe In-Reply-To: <201107062025.p66KPjiT022528@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 6 Jul 2011 23:11:02 +0200 References: <5FDC413D5FA246468C200652D63E627A0F1E306B@LDCMVEXC1-PRD.hq.netapp.com> <201107062025.p66KPjiT022528@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 10679 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 31BD0B015029BA8FAA9241202C005399B9E8E1E0 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1429 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 21:11:38 -0000 On Jul 6, 2011, at 10:25 PM, Bob Briscoe wrote: > Finally, if you want something complex (and difficult), try > implementing an algorithm to derive p from X in the rate equation in > your I-D. I second that. Stein and I spent countless hours trying to produce an efficient fixed point version of our seemingly straightforward extension of that equation, in MulTFRC. (but soon getting close to the finish line, I think / hope) It was quite surprising for us to see how hard that can be. Cheers, Michael From bob.briscoe@bt.com Wed Jul 6 15:52: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 0E7E521F8BDC for ; Wed, 6 Jul 2011 15:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.575, 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 leJvlYdjfsho for ; Wed, 6 Jul 2011 15:52: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 2315321F8BCC for ; Wed, 6 Jul 2011 15:51: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); Wed, 6 Jul 2011 23:51: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); Wed, 6 Jul 2011 23:51: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 1309992717472; Wed, 6 Jul 2011 23:51:57 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.64.12]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p66MptKu022963; Wed, 6 Jul 2011 23:51:56 +0100 Message-Id: <201107062251.p66MptKu022963@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jul 2011 23:51:55 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: References: <201107062025.p66KPjiT022528@bagheera.jungle.bt.co.uk> 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: 06 Jul 2011 22:51:58.0864 (UTC) FILETIME=[4FE81100:01CC3C2F] Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 06 Jul 2011 22:52:02 -0000 Georgios, I think it is best to stop this thread. It is off-charter. And beyond all reasoning. Bob At 22:06 06/07/2011, Georgios Karagiannis wrote: >Hi Bob, > >The I-D uses the RFC5348 (TCP Friendly Rate Control (TFRC)). So the >accuracy of the congestion rate calculation will depend on the accuracy >of TFRC, see also my previous email. > > >Best regards, >Georgios > > > > >On 7/6/2011, "Bob Briscoe" wrote: > > >Georgios, > > > >The dependency goes like this: > > > >1. Actual-Congestion-rate > >2. -> Receiver's-Measured-Congestion-rate > >3. -> Feedback-to-sender > >4. -> Sender's-Measured-Congestion-rate > >5. -> TCP-algo > >6. -> TCP-bit-rate > > > >Information is lost between stages 2-4 because of > >the way TCP feedback works in the case of ECN. So > >(1) =3D (2) <=3D (3) <=3D (4), where <=3D means less than or equal to. > > > >The TCP equation is derived by setting the > >Sender's-Measured-Congestion-rate (stage 4) to p, > >running p through a mathematical model of the > >TCP-algo (stage 5) to derive the TCP-bit-rate (stage 6). > > > >If the sender derives p from its TCP-bit-rate, by > >reversing the theoretical equation, it will get > >metric (4). Unsurprisingly, it will get the > >Congestion-rate that it has been responding to with the TCP algo. > > > >It won't get back any further to metrics 1-3. So > >the approach in your I-D achieves precisely nothing. > > > >Another point: You're confusing complexity with difficulty. > > > >It might be difficult to change the semantics of > >fields in the TCP header (because we have to > >persuade all sorts of strange people at the IETF > >;) But the algorithm to run is not complex - > >receiver adds to a counter, sends the counter in > >a field, sender reads counter, does a subtract > >and shift or two and we're done. There are two > >implementations, and there are a lot more=20 > complicated things in TCP than this. > > > >The really difficult bit of standardisation is > >largely done: we are chartered to produce an > >experimental standard. Importantly, we have one > >good way to negotiate that the new semantics are > >being used, which is essential for backwards > >compatibility. I think Richard & Mirja are right > >to suggest alternatives for the last stage - > >actually doing the feedback. Because reliability > >is quite tough for this - it's OK most of the > >time, but we don't know how prevalent the corner-cases are. > > > >Finally, if you want something complex (and > >difficult), try implementing an algorithm to > >derive p from X in the rate equation in your I-D. > > > >I think you're I-D just shows you've allowed > >yourself to get in a muddle over what depends on what. > > > > > > > >Bob > > > > > >At 20:17 06/07/2011, Georgios Karagiannis wrote: > >>Hi Richard, > >> > >>Please see in line! > >> > >> > >>On 7/6/2011, "Scheffenegger, Richard" wrote: > >> > >> > > >> >Hi Georgios, > >> > > >> >Thanks for the quick reply. > >> > > >> >I'm replying as the co-author of this draft. > >> > > >> >Your comment is only about one (of the three > >> proposed) mechanisms to signal more accurate > >> ECN feedback. As you have noticed, we introduce > >> three different signaling encodings and > >> semantics, each with increasing feature set > >> (and accuracy) over the previous, but also with > >> increasing complexity at implementation. > >> > >>Georgios: Yes, sorry for not mentioning them, I was referring to the= last > >>two solutions. > >> > >> > > >> >Also note, that > >> draft-kuehlewind-conex-accurate-ecn-00, even > >> while submitted in the ConEx WG, really has a > >> broader scope, any deals with the TCP layer > >> alone. Conex is but one possible framework, > >> where this more accurate ECN feedback will be > >> required. Submitting this draft to TCPM was > >> also shortly discussed internally, but ConEx > >> really has a current demand. Nevertheless, the > >> broader scope (and different constraints) of > >> TCP should not get lost when discussing this draft. > >> > >>Georgios: Okay, but my point regarding the fact that the the two latter > >>proposed solutins biy your draft are complex to be deployed, is still > >>valid, since protocol changes need to be accomplished in order to modify > >>the semantics of the TCP header, i.e., the semantics of the flags: NS, > >>CWR and ECE. > >> > >> > > >> > > >> > > >> >Reading your draft, I fail to understand how > >> this may work. Using standard RFC3168 feedback, > >> only a single (!) CE per RTT can be signaled, > >> and then TCP will always react with a single CC > >> response per RTT... regardless of how many CE > >> marks the receiver actually received during=20 > the RTT following the initial CE. > >> > >>Georgios: Note that the solution uses the implementation specified in > >>RFC5348. According to this RFC5348, > >> > >>"The receiver periodically sends feedback messages to the sender. > >> Feedback packets SHOULD normally be sent at least once per RTT, > >> unless the sender is sending at a rate of less than one packet per > >> RTT, in which case a feedback packet SHOULD be sent for every data > >> packet received. A feedback packet SHOULD also be sent whenever a > >> new loss event is detected without waiting for the end of an RTT,= and > >> whenever an out-of-order data packet is received that removes a loss > >> event from the history. > >> > >> If the sender is transmitting at a high rate (many packets per RTT), > >> there may be some advantages to sending periodic feedback messages > >> more than once per RTT as this allows faster response to changing= RTT > >> measurements and more resilience to feedback packet loss." > >> > >> > > >> >Calculating the sending rate at the sender > >> doesn't seem to accomplish what you aim at (or > >> the ingenious idea is missing in that draft). > >> With the widespread adoption of TCP SACK, and > >> alternate congestion controller responses than > >> NewReno (e.g. CUBIC, Compound, ...), the closed > >> formula you quote is only a crude guess at the > >> actual sending rate. These newer TCP congestion > >> control reactions will conform to that formula > >> only under certain (limited) circumstances, at > >> best. (The formula gives a worst case estimate, > >> but the typical sending rate will be higher). > >> Furthermore, the goal of ECN is, to avoid loss > >> (denoted "p" in the formula) due to congestion > >> as much as possible. Because of the limited > >> signal bandwidth (one bit per RTT) of RFC3168, > >> compared to congestion loss (one bit per > >> segment sent - conveyed more or less accurately > >> by ACKs/SACKs), putting standard ECN feedback into "p" will not work. > >> > >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) > >>is used by this solution. So the accuracy of the congestion rate > >>calculation will depend on the accuracy of the TFRC. Moreover, according > >>to RFC5348: > >> "The throughput equation currently REQUIRED for TFRC is a slightly > >> simplified version of the throughput equation for Reno TCP from > >> [PFTK98]. Ideally, we would prefer a throughput equation based on > >> selective acknowledgment (SACK) TCP, but no one has yet derived the > >> throughput equation for SACK TCP, and simulations and experiments > >> suggest that the differences between the two equations would be > >> relatively minor [FF99] (Appendix B).", from [RFC5348] > >> > >>Furthermore, note that p is the rate of loss events and is depending on > >>the loss rate. Loss rate measurement is performed at the receiver, based > >>on the detection of lost or marked packets from the sequence numbers of > >>arriving packets. > >> > >>p can be send from receiver towards the sender in feedback packets. > >>In TFRC several feedback packets can be sent towards the sender within > >>one RTT, depending on the sender data rate. > >> > >> > >> > >> > > >> > > >> >Furthermore, the congestion volume, if I > >> followed ConEx correctly, is the volume of > >> bytes (measured as IP-layer bytes, NOT IP > >> payload, or TCP payload bytes) which were > >> received with CE set. With only a single bit of > >> feedback per RTT, the congestion volume > >> therefore has a lower bound of PMTU bytes per > >> RTT (actually, the minimum packet size > >> possible, when 1-byte TCP payload segments are > >> sent for whatever reason), and an upper bound > >> of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP= Options])+FlightSize. > >> > > >> >Your formula would, as it seems to me, always > >> estimate the congestion volume to be close to > >> cwnd/2 (excluding the IP Header, TCP Headers, > >> and also excluding the actual number of > >> congestions during that RTT). This may be a > >> (very) conservative estimate during low > >> congestion periods, but a very aggressive > >> (=3Dmuch too small) estimate during heavy > >> congestion periods (e.g. 1 RTT, where each segment is CE marked). > >> > >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) > >>is used by this solution. So the accuracy of the congestion rate > >>calculation will depend on the accuracy of the TFRC. > >> > >> > >> > > >> > > >> > > >> >Again, the goal for Accurate ECN feedback is > >> to allow an exact (under common circumstances) > >> feedback of the CE marks as seen by a TCP > >> receiver, to be sent back to the sender. As TCP > >> can not rely on external means to enforce > >> honesty (Conex would be one such external > >> means), ECN Nonce support would be beneficial. > >> > >>Georgios: Yes I agree it might be beneficial. > >> > >> > >> > > >> > > >> >One more word w.r.t. complexity: I believe > >> that the gap between network performance and > >> CPU performance will not shrink in the future. > >> All developments over the last decade points to > >> an ever widening gap. Therefore, schemes which > >> couldn't be hoped to have any chance to be > >> implemented, because of their complexity, such > >> as Conex, are today running at wirespeed in 10G > >> environments. The times, where one major design > >> goal of a protocol was to use as few as > >> possible machine instructions to=20 > encode/decode and interpret, are long past. > >> > > >> >I have seen early SACK and TS work was > >> discussed in terms of number of machine > >> instructions added to the TCP codepath (which > >> is one piece of the puzzle to understand why > >> timestamp semantics are defined the way they are). > >> > > >> >(Also, calculating the integer square root is > >> more involved than doing some bit-banging ;) > >> > >>Georgios: I think that you refer to my statement regarding= implementation > >>complexity of the Re-ECN solution. The term that I have used is not the > >>correct one. I should have used deployment complexity instead of > >>implmentation complexity. > >> > >>Best regards, > >>Georgios > >> > >> > >> > > >> > > >> >Richard Scheffenegger > >> > > >> >> -----Original Message----- > >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> >> Sent: Mittwoch, 06. Juli 2011 14:27 > >> >> To: 'Mirja K=FChlewind'; conex@ietf.org > >> >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > >> >> > >> >> Hi Mirja > >> >> > >> >> I have (quickly) read the document draft-kuehlewind-conex-accurate- > >> >> ecn-00. > >> >> So sorry if I have not understood the concept well! > >> >> > >> >> The described solution in this draft is based on [draft-briscoe- > >> >> tsvwg-re-ecn-tcp-09] and is actually used to > >> >> carry the required feedback from the receiver to the sender such= that > >> >> the > >> >> sender could calculate > >> >> the experienced congestion rate (from sender to receiver). > >> >> > >> >> In my opinion this solution being similar to the one proposed in > >> >> [draft-briscoe- tsvwg-re-ecn-tcp-09] > >> >> seems to be quite complex to be deployed, since protocol changes= need > >> >> to be > >> >> accomplished in order to modify the > >> >> semantics of the TCP header, i.e., the semantics of the flags: NS,= CWR > >> >> and > >> >> ECE. > >> >> > >> >> In > >> >>= http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation- > >> >> 00.txt > >> >> another solution on > >> >> calculating the congestion rate at the sender is described where > >> >> these > >> >> changes in the semantics of > >> >> TCP are not required. > >> >> > >> >> This document provides a solution to this problem as follows, see > >> >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt > >> >> > >> >> When the sender needs to reduce its sending rate, then the sender= can > >> >> calculate the exposed CONGESTION RATE by subtracting the TCP > >> >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) > >> >> from the TCP throughput calculated at the same sender side during= the > >> >> previous RTT, i.e., (RTTi-1), where i is an integer equal or higher > >> >> than 1. > >> >> > >> >> The TCP throughput at the sender side can be calculated using, e.g., > >> >> the following equation specified in [RFC5348]: > >> >> > >> >> > >> >> "The throughput equation for X_Bps, TCP's average sending rate in > >> >> bytes per second, is: > >> >> > >> >> s > >> >> X_Bps =3D= ---------------------------------------------------------- > >> >> R*sqrt(2*b*p/3) + (t_RTO *= (3*sqrt(3*b*p/8)*p*(1+32*p^2))) > >> >> > >> >> Where: > >> >> > >> >> X_Bps is TCP's average transmit rate in bytes per second. = (X_Bps > >> >> is the same as X_calc in RFC 3448.) > >> >> > >> >> s is the segment size in bytes (excluding IP and transport > >> >> protocol headers). > >> >> > >> >> R is the round-trip time in seconds. > >> >> > >> >> p is the loss event rate, between 0 and 1.0, of the number of > >> >> loss > >> >> events as a fraction of the number of packets transmitted. > >> >> > >> >> t_RTO is the TCP retransmission timeout value in seconds. > >> >> > >> >> b is the maximum number of packets acknowledged by a single= TCP > >> >> acknowledgement.", copied from [RFC5368]. > >> >> > >> >> > >> >> Note that the transport path throughput calculated at the sender is > >> >> defined > >> >> as: The per flow transport sending rate as a function of the= congestion > >> >> rate, round-trip time, and segment size. The transport path= throughput > >> >> calculated at the sender using the TCP throughput equation specified= in > >> >> [RFC5348]. Note that in [RFC5348] the term congestion rate is= denoted > >> >> as > >> >> loss event rate. According to [RFC5348] a loss event is defined as= one > >> >> or > >> >> more lost or marked packets from a window of data, where a marked > >> >> packet > >> >> refers to a congestion indication (CE) from Explicit Congestion > >> >> Notification > >> >> (ECN) [RFC3168]; > >> >> > >> >> Best regards, > >> >> Georgios > >> >> > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > >> >> Behalf > >> >> > Of Mirja K=FChlewind > >> >> > Sent: woensdag 6 juli 2011 10:23 > >> >> > To: conex@ietf.org > >> >> > Subject: [conex] New draft(s) on TCP modifications for ConEx > >> >> > > >> >> > Hello, > >> >> > > >> >> > we submitted two new drafts regarding the needed TCP modifications > >> >> for > >> >> > ConEx. > >> >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback > >> >> (more > >> >> than > >> >> > max. one signal per RTT) is needed. The same information would be > >> >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. > >> >> This is > >> >> > why, we decided to split this modification into a separate and= tried > >> >> to > >> >> specify > >> >> > this independent of ConEx. Thus we have two drafts now: > >> >> > > >> >> > 1. draft-kuehlewind-conex-accurate-ecn > >> >> > This draft currently proposes three different coding scheme to > >> >> realize a > >> >> more > >> >> > accurate ECN feedback. All approaches use the available 'classic'= ECN > >> >> bit > >> >> > space as only one mechanism (classic ECN or the new more accurate > >> >> scheme) > >> >> > is needed at a time. The goal is to chose one of the coding= options > >> >> and > >> >> have > >> >> > the other option and all discussions removed at later version of= this > >> >> draft. > >> >> > > >> >> > 2. draft-kuehlewind-conex-tcp-modifications > >> >> > This draft describes all other modifications/recommendations to= use > >> >> ConEx > >> >> > with TCP. This is the use of ECN and SACK and recommendations on= the > >> >> > credit bit. > >> >> > This document contains several points which need further= discussion > >> >> e.g. > >> >> the > >> >> > handling and validity of credits. > >> >> > > >> >> > Please have a look at the drafts; Feedback is very welcome! > >> >> > > >> >> > Mirja and Richard > >> >> > >> >> _______________________________________________ > >> >> 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 ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From bob.briscoe@bt.com Wed Jul 6 16:41: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 991CA21F8893 for ; Wed, 6 Jul 2011 16:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 Y9mXTWbsVN6B for ; Wed, 6 Jul 2011 16:41:27 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 90AB021F888A for ; Wed, 6 Jul 2011 16:41:26 -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, 7 Jul 2011 00:41:25 +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, 7 Jul 2011 00:41:24 +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 1309995684249; Thu, 7 Jul 2011 00:41:24 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.64.12]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p66NfL4j023107; Thu, 7 Jul 2011 00:41:22 +0100 Message-Id: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 00:39:50 +0100 To: John Leslie 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: 06 Jul 2011 23:41:24.0873 (UTC) FILETIME=[37C91F90:01CC3C36] Cc: ConEx IETF list Subject: [conex] Non-goals and/or misconceptions for 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: Wed, 06 Jul 2011 23:41:27 -0000 John, and all, To make this concrete, here's some items I could put in conex-concepts-uses. Some are non-goals. Some are misconceptions. Not in the sense that people are wrong about some objective fact. But in the sense that they are wrong about what ConEx is trying to say. Ie. Misconceptions about ConEx. All, = please suggest which ones are most important to keep, which ones can go, and which ones need clarifying. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 2.2. Common Misconceptions about ConEx Isn't good provisioning the way to solve congestion, not ConEx? This is largely true. However a statement like this contains a number of misconceptions about ConEx: * ConEx is not trying to 'solve' congestion, at least not directly. ConEx is about making congestion visible as a useful metric. * Once congestion-based traffic management is in place, the operator can set a low congestion threshold to trigger and target upgrades to bottlenecks (see Section 5.4). * Removing congestion completely is a non-goal. If an end-to-end transport protocol cannot go fast enough to cause congestion somewhere along the path, it is probably broken. So it is misleading to selectively point to parts of a network (e.g. the core) that are uncongested by design. Application performance depends on the bottleneck, which a good transport protocol will seek out--typically finding it in the access network (or all too often in the receiver's buffer, but that's another story). Low levels of congestion somewhere are therefore healthy. * Congestion and Utilisation are different. Protocols like TCP aim to fill a link so the transfer finishes as quickly as possible. If a link is 10% utilised on average, this can imply it is 100% utilised 10% of the time. Or it might be 10% utilised all the time. Averaging utilisation over a few minutes hides what happened within the averaging time. In contrast, measuring congestion-volume over the same few minutes will distinguish between the two cases. Briscoe & Woundy Expires January 5, 2012 [Page 7] Internet-Draft ConEx Mechanism July 2011 * It is not our place to judge. Many operators choose a mix of traffic management and capacity upgrades, whether they run a University network or a national ISP. Rather than beating our chests about evil traffic management, the idea is to recognise it is a legitimate choice, understand why poor practice is widespread and enable best practice instead. At the same time providing a good metric to support decisions on upgrading bottlenecks too. Exposing Congestion to what? ConEx is about the sender exposing congestion to the network, not the other way round. That would not make sense in the context of the TCP/IP protocol suite, because the end-systems already detect congestion by design. Is the idea for IP routers to use this congestion information? No (but maybe). The sender puts ConEx information in the IP layer so that specific functions can be deployed in the network to use it, e.g. traffic management. These functions might be part of an edge IP router, but might also be a separate box. Some ideas do exist for forwarding on routers to optionally use ConEx (e.g. for preferential discard), but that is not the current focus. Is the idea that network traffic management does congestion control? No. The sender is still expected to do congestion control on fast timescales. The reason the network needs congestion information is not for congestion control, but to arbitrate overall fairness at run-time. But congestion control does fairness, doesn't it? Not really. Congestion control determines the instantaneous shares of some bottleneck links (absent network mechanisms like round-robin scheduling). But it doesn't determine how much data an application transfers, or how many flows it opens, or which congestion control algorithm an application uses, or how many applications the user runs, or how many users are active at once. These factors all determine how great a share of a link is available for any particular data transfer. Network operators use traffic management to ensure some level of overall fairness given all these factors. That's what the congestion information is needed for. So you want the network to enforce compliance to the TCP algorithm? Emphatically no. Some applications would not work if the network forced everything to behave like TCP. This would also prevent deployment of higher performance replacements to TCP. The idea of ConEx is to only enforce overall bulk limits to congestion. Some applications (e.g. short transfers) could be more aggressive than TCP. Others (e.g. long transfers) could be less aggressive, Briscoe & Woundy Expires January 5, 2012 [Page 8] ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Wed Jul 6 22:20: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 CF4FE21F88D9 for ; Wed, 6 Jul 2011 22:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[AWL=0.007, 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 iHu9jNcX8A4u for ; Wed, 6 Jul 2011 22:20:17 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4E21F88D5 for ; Wed, 6 Jul 2011 22:20:16 -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 p675IYok025524; Thu, 7 Jul 2011 07:18:34 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 07 Jul 2011 05:20:14 +0000 To: "Bob Briscoe" Date: Thu, 07 Jul 2011 05:20:13 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107062251.p66MptKu022963@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]); Thu, 07 Jul 2011 07:18:47 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 05:20:19 -0000 Hi Bob, Do you mean that is off-charter because is using for feedback TFRC instead of TCP? Regarding the beyond reasoning statement, it is better to not discuss it via email, but face to face. Will you be in Quebec during the next IETF meeting? Best regards, Georgios On 7/6/2011, "Bob Briscoe" wrote: >Georgios, > >I think it is best to stop this thread. > >It is off-charter. And beyond all reasoning. > > >Bob > >At 22:06 06/07/2011, Georgios Karagiannis wrote: >>Hi Bob, >> >>The I-D uses the RFC5348 (TCP Friendly Rate Control (TFRC)). So the >>accuracy of the congestion rate calculation will depend on the accuracy >>of TFRC, see also my previous email. >> >> >>Best regards, >>Georgios >> >> >> >> >>On 7/6/2011, "Bob Briscoe" wrote: >> >> >Georgios, >> > >> >The dependency goes like this: >> > >> >1. Actual-Congestion-rate >> >2. -> Receiver's-Measured-Congestion-rate >> >3. -> Feedback-to-sender >> >4. -> Sender's-Measured-Congestion-rate >> >5. -> TCP-algo >> >6. -> TCP-bit-rate >> > >> >Information is lost between stages 2-4 because of >> >the way TCP feedback works in the case of ECN. So >> >(1) =3D (2) <=3D (3) <=3D (4), where <=3D means less than or equal to. >> > >> >The TCP equation is derived by setting the >> >Sender's-Measured-Congestion-rate (stage 4) to p, >> >running p through a mathematical model of the >> >TCP-algo (stage 5) to derive the TCP-bit-rate (stage 6). >> > >> >If the sender derives p from its TCP-bit-rate, by >> >reversing the theoretical equation, it will get >> >metric (4). Unsurprisingly, it will get the >> >Congestion-rate that it has been responding to with the TCP algo. >> > >> >It won't get back any further to metrics 1-3. So >> >the approach in your I-D achieves precisely nothing. >> > >> >Another point: You're confusing complexity with difficulty. >> > >> >It might be difficult to change the semantics of >> >fields in the TCP header (because we have to >> >persuade all sorts of strange people at the IETF >> >;) But the algorithm to run is not complex - >> >receiver adds to a counter, sends the counter in >> >a field, sender reads counter, does a subtract >> >and shift or two and we're done. There are two >> >implementations, and there are a lot more=20 >> complicated things in TCP than this. >> > >> >The really difficult bit of standardisation is >> >largely done: we are chartered to produce an >> >experimental standard. Importantly, we have one >> >good way to negotiate that the new semantics are >> >being used, which is essential for backwards >> >compatibility. I think Richard & Mirja are right >> >to suggest alternatives for the last stage - >> >actually doing the feedback. Because reliability >> >is quite tough for this - it's OK most of the >> >time, but we don't know how prevalent the corner-cases are. >> > >> >Finally, if you want something complex (and >> >difficult), try implementing an algorithm to >> >derive p from X in the rate equation in your I-D. >> > >> >I think you're I-D just shows you've allowed >> >yourself to get in a muddle over what depends on what. >> > >> > >> > >> >Bob >> > >> > >> >At 20:17 06/07/2011, Georgios Karagiannis wrote: >> >>Hi Richard, >> >> >> >>Please see in line! >> >> >> >> >> >>On 7/6/2011, "Scheffenegger, Richard" wrote: >> >> >> >> > >> >> >Hi Georgios, >> >> > >> >> >Thanks for the quick reply. >> >> > >> >> >I'm replying as the co-author of this draft. >> >> > >> >> >Your comment is only about one (of the three >> >> proposed) mechanisms to signal more accurate >> >> ECN feedback. As you have noticed, we introduce >> >> three different signaling encodings and >> >> semantics, each with increasing feature set >> >> (and accuracy) over the previous, but also with >> >> increasing complexity at implementation. >> >> >> >>Georgios: Yes, sorry for not mentioning them, I was referring to the las= t >> >>two solutions. >> >> >> >> > >> >> >Also note, that >> >> draft-kuehlewind-conex-accurate-ecn-00, even >> >> while submitted in the ConEx WG, really has a >> >> broader scope, any deals with the TCP layer >> >> alone. Conex is but one possible framework, >> >> where this more accurate ECN feedback will be >> >> required. Submitting this draft to TCPM was >> >> also shortly discussed internally, but ConEx >> >> really has a current demand. Nevertheless, the >> >> broader scope (and different constraints) of >> >> TCP should not get lost when discussing this draft. >> >> >> >>Georgios: Okay, but my point regarding the fact that the the two latter >> >>proposed solutins biy your draft are complex to be deployed, is still >> >>valid, since protocol changes need to be accomplished in order to modify >> >>the semantics of the TCP header, i.e., the semantics of the flags: NS, >> >>CWR and ECE. >> >> >> >> > >> >> > >> >> > >> >> >Reading your draft, I fail to understand how >> >> this may work. Using standard RFC3168 feedback, >> >> only a single (!) CE per RTT can be signaled, >> >> and then TCP will always react with a single CC >> >> response per RTT... regardless of how many CE >> >> marks the receiver actually received during=20 >> the RTT following the initial CE. >> >> >> >>Georgios: Note that the solution uses the implementation specified in >> >>RFC5348. According to this RFC5348, >> >> >> >>"The receiver periodically sends feedback messages to the sender. >> >> Feedback packets SHOULD normally be sent at least once per RTT, >> >> unless the sender is sending at a rate of less than one packet per >> >> RTT, in which case a feedback packet SHOULD be sent for every data >> >> packet received. A feedback packet SHOULD also be sent whenever a >> >> new loss event is detected without waiting for the end of an RTT, an= d >> >> whenever an out-of-order data packet is received that removes a loss >> >> event from the history. >> >> >> >> If the sender is transmitting at a high rate (many packets per RTT), >> >> there may be some advantages to sending periodic feedback messages >> >> more than once per RTT as this allows faster response to changing RT= T >> >> measurements and more resilience to feedback packet loss." >> >> >> >> > >> >> >Calculating the sending rate at the sender >> >> doesn't seem to accomplish what you aim at (or >> >> the ingenious idea is missing in that draft). >> >> With the widespread adoption of TCP SACK, and >> >> alternate congestion controller responses than >> >> NewReno (e.g. CUBIC, Compound, ...), the closed >> >> formula you quote is only a crude guess at the >> >> actual sending rate. These newer TCP congestion >> >> control reactions will conform to that formula >> >> only under certain (limited) circumstances, at >> >> best. (The formula gives a worst case estimate, >> >> but the typical sending rate will be higher). >> >> Furthermore, the goal of ECN is, to avoid loss >> >> (denoted "p" in the formula) due to congestion >> >> as much as possible. Because of the limited >> >> signal bandwidth (one bit per RTT) of RFC3168, >> >> compared to congestion loss (one bit per >> >> segment sent - conveyed more or less accurately >> >> by ACKs/SACKs), putting standard ECN feedback into "p" will not work. >> >> >> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >> >>is used by this solution. So the accuracy of the congestion rate >> >>calculation will depend on the accuracy of the TFRC. Moreover, according >> >>to RFC5348: >> >> "The throughput equation currently REQUIRED for TFRC is a slightly >> >> simplified version of the throughput equation for Reno TCP from >> >> [PFTK98]. Ideally, we would prefer a throughput equation based on >> >> selective acknowledgment (SACK) TCP, but no one has yet derived the >> >> throughput equation for SACK TCP, and simulations and experiments >> >> suggest that the differences between the two equations would be >> >> relatively minor [FF99] (Appendix B).", from [RFC5348] >> >> >> >>Furthermore, note that p is the rate of loss events and is depending on >> >>the loss rate. Loss rate measurement is performed at the receiver, based >> >>on the detection of lost or marked packets from the sequence numbers of >> >>arriving packets. >> >> >> >>p can be send from receiver towards the sender in feedback packets. >> >>In TFRC several feedback packets can be sent towards the sender within >> >>one RTT, depending on the sender data rate. >> >> >> >> >> >> >> >> > >> >> > >> >> >Furthermore, the congestion volume, if I >> >> followed ConEx correctly, is the volume of >> >> bytes (measured as IP-layer bytes, NOT IP >> >> payload, or TCP payload bytes) which were >> >> received with CE set. With only a single bit of >> >> feedback per RTT, the congestion volume >> >> therefore has a lower bound of PMTU bytes per >> >> RTT (actually, the minimum packet size >> >> possible, when 1-byte TCP payload segments are >> >> sent for whatever reason), and an upper bound >> >> of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP Options])+FlightSi= ze. >> >> > >> >> >Your formula would, as it seems to me, always >> >> estimate the congestion volume to be close to >> >> cwnd/2 (excluding the IP Header, TCP Headers, >> >> and also excluding the actual number of >> >> congestions during that RTT). This may be a >> >> (very) conservative estimate during low >> >> congestion periods, but a very aggressive >> >> (=3Dmuch too small) estimate during heavy >> >> congestion periods (e.g. 1 RTT, where each segment is CE marked). >> >> >> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >> >>is used by this solution. So the accuracy of the congestion rate >> >>calculation will depend on the accuracy of the TFRC. >> >> >> >> >> >> > >> >> > >> >> > >> >> >Again, the goal for Accurate ECN feedback is >> >> to allow an exact (under common circumstances) >> >> feedback of the CE marks as seen by a TCP >> >> receiver, to be sent back to the sender. As TCP >> >> can not rely on external means to enforce >> >> honesty (Conex would be one such external >> >> means), ECN Nonce support would be beneficial. >> >> >> >>Georgios: Yes I agree it might be beneficial. >> >> >> >> >> >> > >> >> > >> >> >One more word w.r.t. complexity: I believe >> >> that the gap between network performance and >> >> CPU performance will not shrink in the future. >> >> All developments over the last decade points to >> >> an ever widening gap. Therefore, schemes which >> >> couldn't be hoped to have any chance to be >> >> implemented, because of their complexity, such >> >> as Conex, are today running at wirespeed in 10G >> >> environments. The times, where one major design >> >> goal of a protocol was to use as few as >> >> possible machine instructions to=20 >> encode/decode and interpret, are long past. >> >> > >> >> >I have seen early SACK and TS work was >> >> discussed in terms of number of machine >> >> instructions added to the TCP codepath (which >> >> is one piece of the puzzle to understand why >> >> timestamp semantics are defined the way they are). >> >> > >> >> >(Also, calculating the integer square root is >> >> more involved than doing some bit-banging ;) >> >> >> >>Georgios: I think that you refer to my statement regarding implementatio= n >> >>complexity of the Re-ECN solution. The term that I have used is not the >> >>correct one. I should have used deployment complexity instead of >> >>implmentation complexity. >> >> >> >>Best regards, >> >>Georgios >> >> >> >> >> >> > >> >> > >> >> >Richard Scheffenegger >> >> > >> >> >> -----Original Message----- >> >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >> >> Sent: Mittwoch, 06. Juli 2011 14:27 >> >> >> To: 'Mirja K=FChlewind'; conex@ietf.org >> >> >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >> >> >> >> >> >> Hi Mirja >> >> >> >> >> >> I have (quickly) read the document draft-kuehlewind-conex-accurate- >> >> >> ecn-00. >> >> >> So sorry if I have not understood the concept well! >> >> >> >> >> >> The described solution in this draft is based on [draft-briscoe- >> >> >> tsvwg-re-ecn-tcp-09] and is actually used to >> >> >> carry the required feedback from the receiver to the sender such tha= t >> >> >> the >> >> >> sender could calculate >> >> >> the experienced congestion rate (from sender to receiver). >> >> >> >> >> >> In my opinion this solution being similar to the one proposed in >> >> >> [draft-briscoe- tsvwg-re-ecn-tcp-09] >> >> >> seems to be quite complex to be deployed, since protocol changes nee= d >> >> >> to be >> >> >> accomplished in order to modify the >> >> >> semantics of the TCP header, i.e., the semantics of the flags: NS, = CWR >> >> >> and >> >> >> ECE. >> >> >> >> >> >> In >> >> >> http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculatio= n- >> >> >> 00.txt >> >> >> another solution on >> >> >> calculating the congestion rate at the sender is described where >> >> >> these >> >> >> changes in the semantics of >> >> >> TCP are not required. >> >> >> >> >> >> This document provides a solution to this problem as follows, see >> >> >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt >> >> >> >> >> >> When the sender needs to reduce its sending rate, then the sender c= an >> >> >> calculate the exposed CONGESTION RATE by subtracting the TCP >> >> >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) >> >> >> from the TCP throughput calculated at the same sender side during t= he >> >> >> previous RTT, i.e., (RTTi-1), where i is an integer equal or higher >> >> >> than 1. >> >> >> >> >> >> The TCP throughput at the sender side can be calculated using, e.g., >> >> >> the following equation specified in [RFC5348]: >> >> >> >> >> >> >> >> >> "The throughput equation for X_Bps, TCP's average sending rate in >> >> >> bytes per second, is: >> >> >> >> >> >> s >> >> >> X_Bps =3D -------------------------------------------------------= --- >> >> >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))= ) >> >> >> >> >> >> Where: >> >> >> >> >> >> X_Bps is TCP's average transmit rate in bytes per second. (X_= Bps >> >> >> is the same as X_calc in RFC 3448.) >> >> >> >> >> >> s is the segment size in bytes (excluding IP and transport >> >> >> protocol headers). >> >> >> >> >> >> R is the round-trip time in seconds. >> >> >> >> >> >> p is the loss event rate, between 0 and 1.0, of the number of >> >> >> loss >> >> >> events as a fraction of the number of packets transmitted. >> >> >> >> >> >> t_RTO is the TCP retransmission timeout value in seconds. >> >> >> >> >> >> b is the maximum number of packets acknowledged by a single TC= P >> >> >> acknowledgement.", copied from [RFC5368]. >> >> >> >> >> >> >> >> >> Note that the transport path throughput calculated at the sender is >> >> >> defined >> >> >> as: The per flow transport sending rate as a function of the congest= ion >> >> >> rate, round-trip time, and segment size. The transport path throughp= ut >> >> >> calculated at the sender using the TCP throughput equation specified= in >> >> >> [RFC5348]. Note that in [RFC5348] the term congestion rate is denote= d >> >> >> as >> >> >> loss event rate. According to [RFC5348] a loss event is defined as o= ne >> >> >> or >> >> >> more lost or marked packets from a window of data, where a marked >> >> >> packet >> >> >> refers to a congestion indication (CE) from Explicit Congestion >> >> >> Notification >> >> >> (ECN) [RFC3168]; >> >> >> >> >> >> Best regards, >> >> >> Georgios >> >> >> >> >> >> >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> >> >> Behalf >> >> >> > Of Mirja K=FChlewind >> >> >> > Sent: woensdag 6 juli 2011 10:23 >> >> >> > To: conex@ietf.org >> >> >> > Subject: [conex] New draft(s) on TCP modifications for ConEx >> >> >> > >> >> >> > Hello, >> >> >> > >> >> >> > we submitted two new drafts regarding the needed TCP modifications >> >> >> for >> >> >> > ConEx. >> >> >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback >> >> >> (more >> >> >> than >> >> >> > max. one signal per RTT) is needed. The same information would be >> >> >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. >> >> >> This is >> >> >> > why, we decided to split this modification into a separate and tri= ed >> >> >> to >> >> >> specify >> >> >> > this independent of ConEx. Thus we have two drafts now: >> >> >> > >> >> >> > 1. draft-kuehlewind-conex-accurate-ecn >> >> >> > This draft currently proposes three different coding scheme to >> >> >> realize a >> >> >> more >> >> >> > accurate ECN feedback. All approaches use the available 'classic' = ECN >> >> >> bit >> >> >> > space as only one mechanism (classic ECN or the new more accurate >> >> >> scheme) >> >> >> > is needed at a time. The goal is to chose one of the coding option= s >> >> >> and >> >> >> have >> >> >> > the other option and all discussions removed at later version of t= his >> >> >> draft. >> >> >> > >> >> >> > 2. draft-kuehlewind-conex-tcp-modifications >> >> >> > This draft describes all other modifications/recommendations to us= e >> >> >> ConEx >> >> >> > with TCP. This is the use of ECN and SACK and recommendations on t= he >> >> >> > credit bit. >> >> >> > This document contains several points which need further discussio= n >> >> >> e.g. >> >> >> the >> >> >> > handling and validity of credits. >> >> >> > >> >> >> > Please have a look at the drafts; Feedback is very welcome! >> >> >> > >> >> >> > Mirja and Richard >> >> >> >> >> >> _______________________________________________ >> >> >> 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 > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design=20 From karagian@cs.utwente.nl Wed Jul 6 22:24: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 6DA2921F88C4 for ; Wed, 6 Jul 2011 22:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 BjLNFuzocEB2 for ; Wed, 6 Jul 2011 22:24:11 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id BB84521F88C2 for ; Wed, 6 Jul 2011 22:24:10 -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 p675MY44026227; Thu, 7 Jul 2011 07:22:34 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 07 Jul 2011 05:24:14 +0000 To: "Michael Welzl" , "Bob Briscoe" Date: Thu, 07 Jul 2011 05:24:14 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9A8639FE-FB22-422F-816D-613EE7DBB44E@ifi.uio.no> 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]); Thu, 07 Jul 2011 07:22:43 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 05:24:11 -0000 Hi Michael, Thanks for the information! Best regards, Georgios On 7/6/2011, "Michael Welzl" wrote: > >On Jul 6, 2011, at 10:25 PM, Bob Briscoe wrote: > > > >> Finally, if you want something complex (and difficult), try >> implementing an algorithm to derive p from X in the rate equation in >> your I-D. > >I second that. Stein and I spent countless hours trying to produce an >efficient fixed point version of our seemingly straightforward >extension of that equation, in MulTFRC. >(but soon getting close to the finish line, I think / hope) >It was quite surprising for us to see how hard that can be. > >Cheers, >Michael From karagian@cs.utwente.nl Wed Jul 6 23:08: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 947C321F88C9 for ; Wed, 6 Jul 2011 23:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 lLKGM-BrBgTJ for ; Wed, 6 Jul 2011 23:08:27 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id D0A0121F88C8 for ; Wed, 6 Jul 2011 23:08:26 -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 p6766lRH003714; Thu, 7 Jul 2011 08:06:47 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 07 Jul 2011 06:08:27 +0000 To: "Bob Briscoe" Date: Thu, 07 Jul 2011 06:08:26 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: 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]); Thu, 07 Jul 2011 08:06:59 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 06:08:28 -0000 Hi Bob, This was too early for me! In the below email I meant: Do you mean that is off-charter because is using for feedback DCCP & TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? Best regards, Georgios On 7/7/2011, "Georgios Karagiannis" wrote: >Hi Bob, > >Do you mean that is off-charter because is using for feedback TFRC >instead of TCP? > >Regarding the beyond reasoning statement, it is better to not discuss it >via email, but face to face. Will you be in Quebec during the next IETF >meeting? > >Best regards, >Georgios > >On 7/6/2011, "Bob Briscoe" wrote: > >>Georgios, >> >>I think it is best to stop this thread. >> >>It is off-charter. And beyond all reasoning. >> >> >>Bob >> >>At 22:06 06/07/2011, Georgios Karagiannis wrote: >>>Hi Bob, >>> >>>The I-D uses the RFC5348 (TCP Friendly Rate Control (TFRC)). So the >>>accuracy of the congestion rate calculation will depend on the accuracy >>>of TFRC, see also my previous email. >>> >>> >>>Best regards, >>>Georgios >>> >>> >>> >>> >>>On 7/6/2011, "Bob Briscoe" wrote: >>> >>> >Georgios, >>> > >>> >The dependency goes like this: >>> > >>> >1. Actual-Congestion-rate >>> >2. -> Receiver's-Measured-Congestion-rate >>> >3. -> Feedback-to-sender >>> >4. -> Sender's-Measured-Congestion-rate >>> >5. -> TCP-algo >>> >6. -> TCP-bit-rate >>> > >>> >Information is lost between stages 2-4 because of >>> >the way TCP feedback works in the case of ECN. So >>> >(1) =3D (2) <=3D (3) <=3D (4), where <=3D means less than or equal to. >>> > >>> >The TCP equation is derived by setting the >>> >Sender's-Measured-Congestion-rate (stage 4) to p, >>> >running p through a mathematical model of the >>> >TCP-algo (stage 5) to derive the TCP-bit-rate (stage 6). >>> > >>> >If the sender derives p from its TCP-bit-rate, by >>> >reversing the theoretical equation, it will get >>> >metric (4). Unsurprisingly, it will get the >>> >Congestion-rate that it has been responding to with the TCP algo. >>> > >>> >It won't get back any further to metrics 1-3. So >>> >the approach in your I-D achieves precisely nothing. >>> > >>> >Another point: You're confusing complexity with difficulty. >>> > >>> >It might be difficult to change the semantics of >>> >fields in the TCP header (because we have to >>> >persuade all sorts of strange people at the IETF >>> >;) But the algorithm to run is not complex - >>> >receiver adds to a counter, sends the counter in >>> >a field, sender reads counter, does a subtract >>> >and shift or two and we're done. There are two >>> >implementations, and there are a lot more=20 >>> complicated things in TCP than this. >>> > >>> >The really difficult bit of standardisation is >>> >largely done: we are chartered to produce an >>> >experimental standard. Importantly, we have one >>> >good way to negotiate that the new semantics are >>> >being used, which is essential for backwards >>> >compatibility. I think Richard & Mirja are right >>> >to suggest alternatives for the last stage - >>> >actually doing the feedback. Because reliability >>> >is quite tough for this - it's OK most of the >>> >time, but we don't know how prevalent the corner-cases are. >>> > >>> >Finally, if you want something complex (and >>> >difficult), try implementing an algorithm to >>> >derive p from X in the rate equation in your I-D. >>> > >>> >I think you're I-D just shows you've allowed >>> >yourself to get in a muddle over what depends on what. >>> > >>> > >>> > >>> >Bob >>> > >>> > >>> >At 20:17 06/07/2011, Georgios Karagiannis wrote: >>> >>Hi Richard, >>> >> >>> >>Please see in line! >>> >> >>> >> >>> >>On 7/6/2011, "Scheffenegger, Richard" wrote: >>> >> >>> >> > >>> >> >Hi Georgios, >>> >> > >>> >> >Thanks for the quick reply. >>> >> > >>> >> >I'm replying as the co-author of this draft. >>> >> > >>> >> >Your comment is only about one (of the three >>> >> proposed) mechanisms to signal more accurate >>> >> ECN feedback. As you have noticed, we introduce >>> >> three different signaling encodings and >>> >> semantics, each with increasing feature set >>> >> (and accuracy) over the previous, but also with >>> >> increasing complexity at implementation. >>> >> >>> >>Georgios: Yes, sorry for not mentioning them, I was referring to the la= st >>> >>two solutions. >>> >> >>> >> > >>> >> >Also note, that >>> >> draft-kuehlewind-conex-accurate-ecn-00, even >>> >> while submitted in the ConEx WG, really has a >>> >> broader scope, any deals with the TCP layer >>> >> alone. Conex is but one possible framework, >>> >> where this more accurate ECN feedback will be >>> >> required. Submitting this draft to TCPM was >>> >> also shortly discussed internally, but ConEx >>> >> really has a current demand. Nevertheless, the >>> >> broader scope (and different constraints) of >>> >> TCP should not get lost when discussing this draft. >>> >> >>> >>Georgios: Okay, but my point regarding the fact that the the two latter >>> >>proposed solutins biy your draft are complex to be deployed, is still >>> >>valid, since protocol changes need to be accomplished in order to modif= y >>> >>the semantics of the TCP header, i.e., the semantics of the flags: NS, >>> >>CWR and ECE. >>> >> >>> >> > >>> >> > >>> >> > >>> >> >Reading your draft, I fail to understand how >>> >> this may work. Using standard RFC3168 feedback, >>> >> only a single (!) CE per RTT can be signaled, >>> >> and then TCP will always react with a single CC >>> >> response per RTT... regardless of how many CE >>> >> marks the receiver actually received during=20 >>> the RTT following the initial CE. >>> >> >>> >>Georgios: Note that the solution uses the implementation specified in >>> >>RFC5348. According to this RFC5348, >>> >> >>> >>"The receiver periodically sends feedback messages to the sender. >>> >> Feedback packets SHOULD normally be sent at least once per RTT, >>> >> unless the sender is sending at a rate of less than one packet per >>> >> RTT, in which case a feedback packet SHOULD be sent for every data >>> >> packet received. A feedback packet SHOULD also be sent whenever a >>> >> new loss event is detected without waiting for the end of an RTT, a= nd >>> >> whenever an out-of-order data packet is received that removes a los= s >>> >> event from the history. >>> >> >>> >> If the sender is transmitting at a high rate (many packets per RTT)= , >>> >> there may be some advantages to sending periodic feedback messages >>> >> more than once per RTT as this allows faster response to changing R= TT >>> >> measurements and more resilience to feedback packet loss." >>> >> >>> >> > >>> >> >Calculating the sending rate at the sender >>> >> doesn't seem to accomplish what you aim at (or >>> >> the ingenious idea is missing in that draft). >>> >> With the widespread adoption of TCP SACK, and >>> >> alternate congestion controller responses than >>> >> NewReno (e.g. CUBIC, Compound, ...), the closed >>> >> formula you quote is only a crude guess at the >>> >> actual sending rate. These newer TCP congestion >>> >> control reactions will conform to that formula >>> >> only under certain (limited) circumstances, at >>> >> best. (The formula gives a worst case estimate, >>> >> but the typical sending rate will be higher). >>> >> Furthermore, the goal of ECN is, to avoid loss >>> >> (denoted "p" in the formula) due to congestion >>> >> as much as possible. Because of the limited >>> >> signal bandwidth (one bit per RTT) of RFC3168, >>> >> compared to congestion loss (one bit per >>> >> segment sent - conveyed more or less accurately >>> >> by ACKs/SACKs), putting standard ECN feedback into "p" will not work. >>> >> >>> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >>> >>is used by this solution. So the accuracy of the congestion rate >>> >>calculation will depend on the accuracy of the TFRC. Moreover, accordin= g >>> >>to RFC5348: >>> >> "The throughput equation currently REQUIRED for TFRC is a slightly >>> >> simplified version of the throughput equation for Reno TCP from >>> >> [PFTK98]. Ideally, we would prefer a throughput equation based on >>> >> selective acknowledgment (SACK) TCP, but no one has yet derived the >>> >> throughput equation for SACK TCP, and simulations and experiments >>> >> suggest that the differences between the two equations would be >>> >> relatively minor [FF99] (Appendix B).", from [RFC5348] >>> >> >>> >>Furthermore, note that p is the rate of loss events and is depending on >>> >>the loss rate. Loss rate measurement is performed at the receiver, base= d >>> >>on the detection of lost or marked packets from the sequence numbers of >>> >>arriving packets. >>> >> >>> >>p can be send from receiver towards the sender in feedback packets. >>> >>In TFRC several feedback packets can be sent towards the sender within >>> >>one RTT, depending on the sender data rate. >>> >> >>> >> >>> >> >>> >> > >>> >> > >>> >> >Furthermore, the congestion volume, if I >>> >> followed ConEx correctly, is the volume of >>> >> bytes (measured as IP-layer bytes, NOT IP >>> >> payload, or TCP payload bytes) which were >>> >> received with CE set. With only a single bit of >>> >> feedback per RTT, the congestion volume >>> >> therefore has a lower bound of PMTU bytes per >>> >> RTT (actually, the minimum packet size >>> >> possible, when 1-byte TCP payload segments are >>> >> sent for whatever reason), and an upper bound >>> >> of floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP Options])+FlightS= ize. >>> >> > >>> >> >Your formula would, as it seems to me, always >>> >> estimate the congestion volume to be close to >>> >> cwnd/2 (excluding the IP Header, TCP Headers, >>> >> and also excluding the actual number of >>> >> congestions during that RTT). This may be a >>> >> (very) conservative estimate during low >>> >> congestion periods, but a very aggressive >>> >> (=3Dmuch too small) estimate during heavy >>> >> congestion periods (e.g. 1 RTT, where each segment is CE marked). >>> >> >>> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control (TFRC)) >>> >>is used by this solution. So the accuracy of the congestion rate >>> >>calculation will depend on the accuracy of the TFRC. >>> >> >>> >> >>> >> > >>> >> > >>> >> > >>> >> >Again, the goal for Accurate ECN feedback is >>> >> to allow an exact (under common circumstances) >>> >> feedback of the CE marks as seen by a TCP >>> >> receiver, to be sent back to the sender. As TCP >>> >> can not rely on external means to enforce >>> >> honesty (Conex would be one such external >>> >> means), ECN Nonce support would be beneficial. >>> >> >>> >>Georgios: Yes I agree it might be beneficial. >>> >> >>> >> >>> >> > >>> >> > >>> >> >One more word w.r.t. complexity: I believe >>> >> that the gap between network performance and >>> >> CPU performance will not shrink in the future. >>> >> All developments over the last decade points to >>> >> an ever widening gap. Therefore, schemes which >>> >> couldn't be hoped to have any chance to be >>> >> implemented, because of their complexity, such >>> >> as Conex, are today running at wirespeed in 10G >>> >> environments. The times, where one major design >>> >> goal of a protocol was to use as few as >>> >> possible machine instructions to=20 >>> encode/decode and interpret, are long past. >>> >> > >>> >> >I have seen early SACK and TS work was >>> >> discussed in terms of number of machine >>> >> instructions added to the TCP codepath (which >>> >> is one piece of the puzzle to understand why >>> >> timestamp semantics are defined the way they are). >>> >> > >>> >> >(Also, calculating the integer square root is >>> >> more involved than doing some bit-banging ;) >>> >> >>> >>Georgios: I think that you refer to my statement regarding implementati= on >>> >>complexity of the Re-ECN solution. The term that I have used is not the >>> >>correct one. I should have used deployment complexity instead of >>> >>implmentation complexity. >>> >> >>> >>Best regards, >>> >>Georgios >>> >> >>> >> >>> >> > >>> >> > >>> >> >Richard Scheffenegger >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>> >> >> Sent: Mittwoch, 06. Juli 2011 14:27 >>> >> >> To: 'Mirja K=FChlewind'; conex@ietf.org >>> >> >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >>> >> >> >>> >> >> Hi Mirja >>> >> >> >>> >> >> I have (quickly) read the document draft-kuehlewind-conex-accurate= - >>> >> >> ecn-00. >>> >> >> So sorry if I have not understood the concept well! >>> >> >> >>> >> >> The described solution in this draft is based on [draft-briscoe- >>> >> >> tsvwg-re-ecn-tcp-09] and is actually used to >>> >> >> carry the required feedback from the receiver to the sender such th= at >>> >> >> the >>> >> >> sender could calculate >>> >> >> the experienced congestion rate (from sender to receiver). >>> >> >> >>> >> >> In my opinion this solution being similar to the one proposed in >>> >> >> [draft-briscoe- tsvwg-re-ecn-tcp-09] >>> >> >> seems to be quite complex to be deployed, since protocol changes ne= ed >>> >> >> to be >>> >> >> accomplished in order to modify the >>> >> >> semantics of the TCP header, i.e., the semantics of the flags: NS,= CWR >>> >> >> and >>> >> >> ECE. >>> >> >> >>> >> >> In >>> >> >> http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculati= on- >>> >> >> 00.txt >>> >> >> another solution on >>> >> >> calculating the congestion rate at the sender is described where >>> >> >> these >>> >> >> changes in the semantics of >>> >> >> TCP are not required. >>> >> >> >>> >> >> This document provides a solution to this problem as follows, see >>> >> >> Figure 2. in draft-karagiannis-conex-congestion-calculation-00.txt >>> >> >> >>> >> >> When the sender needs to reduce its sending rate, then the sender = can >>> >> >> calculate the exposed CONGESTION RATE by subtracting the TCP >>> >> >> throughput calculated during a Round Trip Time (RTT), i.e., (RTTi) >>> >> >> from the TCP throughput calculated at the same sender side during = the >>> >> >> previous RTT, i.e., (RTTi-1), where i is an integer equal or highe= r >>> >> >> than 1. >>> >> >> >>> >> >> The TCP throughput at the sender side can be calculated using, e.g.= , >>> >> >> the following equation specified in [RFC5348]: >>> >> >> >>> >> >> >>> >> >> "The throughput equation for X_Bps, TCP's average sending rate i= n >>> >> >> bytes per second, is: >>> >> >> >>> >> >> s >>> >> >> X_Bps =3D ------------------------------------------------------= ---- >>> >> >> R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)= )) >>> >> >> >>> >> >> Where: >>> >> >> >>> >> >> X_Bps is TCP's average transmit rate in bytes per second. (X= _Bps >>> >> >> is the same as X_calc in RFC 3448.) >>> >> >> >>> >> >> s is the segment size in bytes (excluding IP and transport >>> >> >> protocol headers). >>> >> >> >>> >> >> R is the round-trip time in seconds. >>> >> >> >>> >> >> p is the loss event rate, between 0 and 1.0, of the number of >>> >> >> loss >>> >> >> events as a fraction of the number of packets transmitted. >>> >> >> >>> >> >> t_RTO is the TCP retransmission timeout value in seconds. >>> >> >> >>> >> >> b is the maximum number of packets acknowledged by a single T= CP >>> >> >> acknowledgement.", copied from [RFC5368]. >>> >> >> >>> >> >> >>> >> >> Note that the transport path throughput calculated at the sender is >>> >> >> defined >>> >> >> as: The per flow transport sending rate as a function of the conges= tion >>> >> >> rate, round-trip time, and segment size. The transport path through= put >>> >> >> calculated at the sender using the TCP throughput equation specifie= d in >>> >> >> [RFC5348]. Note that in [RFC5348] the term congestion rate is denot= ed >>> >> >> as >>> >> >> loss event rate. According to [RFC5348] a loss event is defined as = one >>> >> >> or >>> >> >> more lost or marked packets from a window of data, where a marked >>> >> >> packet >>> >> >> refers to a congestion indication (CE) from Explicit Congestion >>> >> >> Notification >>> >> >> (ECN) [RFC3168]; >>> >> >> >>> >> >> Best regards, >>> >> >> Georgios >>> >> >> >>> >> >> >>> >> >> >>> >> >> > -----Original Message----- >>> >> >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >>> >> >> Behalf >>> >> >> > Of Mirja K=FChlewind >>> >> >> > Sent: woensdag 6 juli 2011 10:23 >>> >> >> > To: conex@ietf.org >>> >> >> > Subject: [conex] New draft(s) on TCP modifications for ConEx >>> >> >> > >>> >> >> > Hello, >>> >> >> > >>> >> >> > we submitted two new drafts regarding the needed TCP modification= s >>> >> >> for >>> >> >> > ConEx. >>> >> >> > As ConEx relies (partially) on ECN, a more accurate ECN feedback >>> >> >> (more >>> >> >> than >>> >> >> > max. one signal per RTT) is needed. The same information would be >>> >> >> > valuebale for other currently proposed TCP mechanisms e.g. DCTCP. >>> >> >> This is >>> >> >> > why, we decided to split this modification into a separate and tr= ied >>> >> >> to >>> >> >> specify >>> >> >> > this independent of ConEx. Thus we have two drafts now: >>> >> >> > >>> >> >> > 1. draft-kuehlewind-conex-accurate-ecn >>> >> >> > This draft currently proposes three different coding scheme to >>> >> >> realize a >>> >> >> more >>> >> >> > accurate ECN feedback. All approaches use the available 'classic'= ECN >>> >> >> bit >>> >> >> > space as only one mechanism (classic ECN or the new more accurate >>> >> >> scheme) >>> >> >> > is needed at a time. The goal is to chose one of the coding optio= ns >>> >> >> and >>> >> >> have >>> >> >> > the other option and all discussions removed at later version of = this >>> >> >> draft. >>> >> >> > >>> >> >> > 2. draft-kuehlewind-conex-tcp-modifications >>> >> >> > This draft describes all other modifications/recommendations to u= se >>> >> >> ConEx >>> >> >> > with TCP. This is the use of ECN and SACK and recommendations on = the >>> >> >> > credit bit. >>> >> >> > This document contains several points which need further discussi= on >>> >> >> e.g. >>> >> >> the >>> >> >> > handling and validity of credits. >>> >> >> > >>> >> >> > Please have a look at the drafts; Feedback is very welcome! >>> >> >> > >>> >> >> > Mirja and Richard >>> >> >> >>> >> >> _______________________________________________ >>> >> >> 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 >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design=20 >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From menth@informatik.uni-tuebingen.de Thu Jul 7 00:54:07 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 364D621F88DB for ; Thu, 7 Jul 2011 00:54:07 -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 itHmqW6kAeyn for ; Thu, 7 Jul 2011 00:54:06 -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 50DC021F88D5 for ; Thu, 7 Jul 2011 00:54:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 51C6252AB; Thu, 7 Jul 2011 09:54:00 +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 bTO9s59jgz7d; Thu, 7 Jul 2011 09:53:54 +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 5865B5230; Thu, 7 Jul 2011 09:53: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 2D7D31216FD9; Thu, 7 Jul 2011 09:53:54 +0200 (CEST) Message-ID: <4E156612.5030409@informatik.uni-tuebingen.de> Date: Thu, 07 Jul 2011 09:53:54 +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: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> In-Reply-To: <201107062341.p66NfL4j023107@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] Non-goals and/or misconceptions for 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, 07 Jul 2011 07:54:07 -0000 Hi Bob, Am 07.07.2011 01:39, schrieb Bob Briscoe: > John, and all, > > To make this concrete, here's some items I could put in > conex-concepts-uses. > > Some are non-goals. Some are misconceptions. Not in the sense that > people are wrong about some objective fact. But in the sense that they > are wrong about what ConEx is trying to say. Ie. Misconceptions about > ConEx. > > All, = please suggest which ones are most important to keep, which > ones can go, and which ones need clarifying. I'd put such a section rather at the end or in the appendix of the document. Just brief feedback. > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > 2.2. Common Misconceptions about ConEx > > Isn't good provisioning the way to solve congestion, not ConEx? > This is largely true. However a statement like this contains a > number of misconceptions about ConEx: > > * ConEx is not trying to 'solve' congestion, at least not > directly. ConEx is about making congestion visible as a useful > metric. > > * Once congestion-based traffic management is in place, the > operator can set a low congestion threshold to trigger and > target upgrades to bottlenecks (see Section 5.4). ... can use congestion information to trigger ... > > * Removing congestion completely is a non-goal. If an end-to-end > transport protocol cannot go fast enough to cause congestion > somewhere along the path, it is probably broken. So it is > misleading to selectively point to parts of a network (e.g. the > core) that are uncongested by design. Application performance > depends on the bottleneck, which a good transport protocol will > seek out--typically finding it in the access network (or all > too often in the receiver's buffer, but that's another story). > Low levels of congestion somewhere are therefore healthy. > > * Congestion and Utilisation are different. Protocols like TCP > aim to fill a link so the transfer finishes as quickly as > possible. If a link is 10% utilised on average, this can imply > it is 100% utilised 10% of the time. Or it might be 10% > utilised all the time. Averaging utilisation over a few > minutes hides what happened within the averaging time. In > contrast, measuring congestion-volume over the same few minutes > will distinguish between the two cases. The link to the major point must be better worked out. > > > > > Briscoe & Woundy Expires January 5, 2012 [Page 7] > > Internet-Draft ConEx Mechanism July 2011 > > > * It is not our place to judge. Many operators choose a mix of > traffic management and capacity upgrades, whether they run a > University network or a national ISP. Rather than beating our > chests about evil traffic management, the idea is to recognise > it is a legitimate choice, understand why poor practice is > widespread and enable best practice instead. At the same time > providing a good metric to support decisions on upgrading > bottlenecks too. Hm, difficult. Definitely needs rewording. > > Exposing Congestion to what? ConEx is about the sender exposing > congestion to the network, not the other way round. That would > not make sense in the context of the TCP/IP protocol suite, > because the end-systems already detect congestion by design. > > Is the idea for IP routers to use this congestion information? No > (but maybe). The sender puts ConEx information in the IP layer so > that specific functions can be deployed in the network to use it, > e.g. traffic management. These functions might be part of an edge > IP router, but might also be a separate box. Some ideas do exist > for forwarding on routers to optionally use ConEx (e.g. for > preferential discard), but that is not the current focus. > > Is the idea that network traffic management does congestion control? > No. The sender is still expected to do congestion control on fast > timescales. The reason the network needs congestion information > is not for congestion control, but to arbitrate overall fairness > at run-time. The meaning of the last sentence is not fully clear. > > But congestion control does fairness, doesn't it? Not really. > Congestion control determines the instantaneous shares of some > bottleneck links (absent network mechanisms like round-robin > scheduling). But it doesn't determine how much data an > application transfers, or how many flows it opens, or which > congestion control algorithm an application uses, or how many > applications the user runs, or how many users are active at once. > These factors all determine how great a share of a link is > available for any particular data transfer. Network operators use > traffic management to ensure some level of overall fairness given > all these factors. That's what the congestion information is > needed for. Should be dropped or reformulated. > > So you want the network to enforce compliance to the TCP algorithm? > Emphatically no. Some applications would not work if the network > forced everything to behave like TCP. This would also prevent > deployment of higher performance replacements to TCP. The idea of > ConEx is to only enforce overall bulk limits to congestion. Some > applications (e.g. short transfers) could be more aggressive than > TCP. Others (e.g. long transfers) could be less aggressive, > Interesting point, good to mention. Regards, Michael > > > Briscoe & Woundy Expires January 5, 2012 [Page 8] > > > > > > ________________________________________________________________ > 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 bob.briscoe@bt.com Thu Jul 7 02:28: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 93D6221F87A8 for ; Thu, 7 Jul 2011 02:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.551, 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 uxCQfOJrImiv for ; Thu, 7 Jul 2011 02:28:12 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 9818921F8677 for ; Thu, 7 Jul 2011 02:28:11 -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); Thu, 7 Jul 2011 10:28:09 +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, 7 Jul 2011 10:28:09 +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 1310030888753; Thu, 7 Jul 2011 10:28:08 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.194.135]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p679S69A025144; Thu, 7 Jul 2011 10:28:07 +0100 Message-Id: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 10:28:09 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: References: 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: 07 Jul 2011 09:28:09.0582 (UTC) FILETIME=[2F6D68E0:01CC3C88] Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 09:28:13 -0000 Georgios, >On 7/7/2011, "Georgios Karagiannis" wrote: > >Regarding the beyond reasoning statement, it is better to not discuss it > >via email, but face to face. Will you be in Quebec during the next IETF > >meeting? I meant that your response was not engaging in the reasoning put to you. You can go back and respond to the reasoning=20 already given. But I don't need to say any more. My main point was that the whole idea of your=20 draft goes round in a loop that achieves nothing.=20 You avoided this critical point and jumped to a=20 detail (a detail within that loop that already achieves nothing). Now you are saying you meant something very=20 different to what you had written (you now say=20 the draft was about DCCP, but the title of your=20 draft says it is about TCP and DCCP isn't=20 mentioned). Anyway, DCCP takes you off-charter instead (see below). At 07:08 07/07/2011, Georgios Karagiannis wrote: >Do you mean that is off-charter because is using for feedback DCCP & TFRC >(RFC5348, RFC5622, RFC4342) instead of TCP? Yes. ConEx is primarily at the IP layer, but some=20 transports need optional changes to their=20 feedback. The charter says we will focus on TCP first. You are criticising a draft written to satisfy=20 this charter objective. You are saying it is=20 difficult to change the semantics of TCP header=20 fields (which we are already chartered to do). So=20 you propose everyone should have to use DCCP in=20 order to use ConEx. That would require every=20 application in the world that uses TCP to be=20 changed to call DCCP instead, in order to use=20 ConEx. And most middleboxes (NATs, firewalls) would have to be changed too. When you're in a hole, stop digging. Bob > > > >Best regards, > >Georgios > > > >On 7/6/2011, "Bob Briscoe" wrote: > > > >>Georgios, > >> > >>I think it is best to stop this thread. > >> > >>It is off-charter. And beyond all reasoning. > >> > >> > >>Bob > >> > >>At 22:06 06/07/2011, Georgios Karagiannis wrote: > >>>Hi Bob, > >>> > >>>The I-D uses the RFC5348 (TCP Friendly Rate Control (TFRC)). So the > >>>accuracy of the congestion rate calculation will depend on the accuracy > >>>of TFRC, see also my previous email. > >>> > >>> > >>>Best regards, > >>>Georgios > >>> > >>> > >>> > >>> > >>>On 7/6/2011, "Bob Briscoe" wrote: > >>> > >>> >Georgios, > >>> > > >>> >The dependency goes like this: > >>> > > >>> >1. Actual-Congestion-rate > >>> >2. -> Receiver's-Measured-Congestion-rate > >>> >3. -> Feedback-to-sender > >>> >4. -> Sender's-Measured-Congestion-rate > >>> >5. -> TCP-algo > >>> >6. -> TCP-bit-rate > >>> > > >>> >Information is lost between stages 2-4 because of > >>> >the way TCP feedback works in the case of ECN. So > >>> >(1) =3D (2) <=3D (3) <=3D (4), where <=3D means less than or equal= to. > >>> > > >>> >The TCP equation is derived by setting the > >>> >Sender's-Measured-Congestion-rate (stage 4) to p, > >>> >running p through a mathematical model of the > >>> >TCP-algo (stage 5) to derive the TCP-bit-rate (stage 6). > >>> > > >>> >If the sender derives p from its TCP-bit-rate, by > >>> >reversing the theoretical equation, it will get > >>> >metric (4). Unsurprisingly, it will get the > >>> >Congestion-rate that it has been responding to with the TCP algo. > >>> > > >>> >It won't get back any further to metrics 1-3. So > >>> >the approach in your I-D achieves precisely nothing. > >>> > > >>> >Another point: You're confusing complexity with difficulty. > >>> > > >>> >It might be difficult to change the semantics of > >>> >fields in the TCP header (because we have to > >>> >persuade all sorts of strange people at the IETF > >>> >;) But the algorithm to run is not complex - > >>> >receiver adds to a counter, sends the counter in > >>> >a field, sender reads counter, does a subtract > >>> >and shift or two and we're done. There are two > >>> >implementations, and there are a lot more > >>> complicated things in TCP than this. > >>> > > >>> >The really difficult bit of standardisation is > >>> >largely done: we are chartered to produce an > >>> >experimental standard. Importantly, we have one > >>> >good way to negotiate that the new semantics are > >>> >being used, which is essential for backwards > >>> >compatibility. I think Richard & Mirja are right > >>> >to suggest alternatives for the last stage - > >>> >actually doing the feedback. Because reliability > >>> >is quite tough for this - it's OK most of the > >>> >time, but we don't know how prevalent the corner-cases are. > >>> > > >>> >Finally, if you want something complex (and > >>> >difficult), try implementing an algorithm to > >>> >derive p from X in the rate equation in your I-D. > >>> > > >>> >I think you're I-D just shows you've allowed > >>> >yourself to get in a muddle over what depends on what. > >>> > > >>> > > >>> > > >>> >Bob > >>> > > >>> > > >>> >At 20:17 06/07/2011, Georgios Karagiannis wrote: > >>> >>Hi Richard, > >>> >> > >>> >>Please see in line! > >>> >> > >>> >> > >>> >>On 7/6/2011, "Scheffenegger, Richard" wrote: > >>> >> > >>> >> > > >>> >> >Hi Georgios, > >>> >> > > >>> >> >Thanks for the quick reply. > >>> >> > > >>> >> >I'm replying as the co-author of this draft. > >>> >> > > >>> >> >Your comment is only about one (of the three > >>> >> proposed) mechanisms to signal more accurate > >>> >> ECN feedback. As you have noticed, we introduce > >>> >> three different signaling encodings and > >>> >> semantics, each with increasing feature set > >>> >> (and accuracy) over the previous, but also with > >>> >> increasing complexity at implementation. > >>> >> > >>> >>Georgios: Yes, sorry for not mentioning=20 > them, I was referring to the last > >>> >>two solutions. > >>> >> > >>> >> > > >>> >> >Also note, that > >>> >> draft-kuehlewind-conex-accurate-ecn-00, even > >>> >> while submitted in the ConEx WG, really has a > >>> >> broader scope, any deals with the TCP layer > >>> >> alone. Conex is but one possible framework, > >>> >> where this more accurate ECN feedback will be > >>> >> required. Submitting this draft to TCPM was > >>> >> also shortly discussed internally, but ConEx > >>> >> really has a current demand. Nevertheless, the > >>> >> broader scope (and different constraints) of > >>> >> TCP should not get lost when discussing this draft. > >>> >> > >>> >>Georgios: Okay, but my point regarding the fact that the the two= latter > >>> >>proposed solutins biy your draft are complex to be deployed, is= still > >>> >>valid, since protocol changes need to be=20 > accomplished in order to modify > >>> >>the semantics of the TCP header, i.e., the semantics of the flags:= NS, > >>> >>CWR and ECE. > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> >Reading your draft, I fail to understand how > >>> >> this may work. Using standard RFC3168 feedback, > >>> >> only a single (!) CE per RTT can be signaled, > >>> >> and then TCP will always react with a single CC > >>> >> response per RTT... regardless of how many CE > >>> >> marks the receiver actually received during > >>> the RTT following the initial CE. > >>> >> > >>> >>Georgios: Note that the solution uses the implementation specified= in > >>> >>RFC5348. According to this RFC5348, > >>> >> > >>> >>"The receiver periodically sends feedback messages to the sender. > >>> >> Feedback packets SHOULD normally be sent at least once per RTT, > >>> >> unless the sender is sending at a rate of less than one packet= per > >>> >> RTT, in which case a feedback packet SHOULD be sent for every= data > >>> >> packet received. A feedback packet SHOULD also be sent whenever= a > >>> >> new loss event is detected without=20 > waiting for the end of an RTT, and > >>> >> whenever an out-of-order data packet=20 > is received that removes a loss > >>> >> event from the history. > >>> >> > >>> >> If the sender is transmitting at a=20 > high rate (many packets per RTT), > >>> >> there may be some advantages to sending periodic feedback= messages > >>> >> more than once per RTT as this allows=20 > faster response to changing RTT > >>> >> measurements and more resilience to feedback packet loss." > >>> >> > >>> >> > > >>> >> >Calculating the sending rate at the sender > >>> >> doesn't seem to accomplish what you aim at (or > >>> >> the ingenious idea is missing in that draft). > >>> >> With the widespread adoption of TCP SACK, and > >>> >> alternate congestion controller responses than > >>> >> NewReno (e.g. CUBIC, Compound, ...), the closed > >>> >> formula you quote is only a crude guess at the > >>> >> actual sending rate. These newer TCP congestion > >>> >> control reactions will conform to that formula > >>> >> only under certain (limited) circumstances, at > >>> >> best. (The formula gives a worst case estimate, > >>> >> but the typical sending rate will be higher). > >>> >> Furthermore, the goal of ECN is, to avoid loss > >>> >> (denoted "p" in the formula) due to congestion > >>> >> as much as possible. Because of the limited > >>> >> signal bandwidth (one bit per RTT) of RFC3168, > >>> >> compared to congestion loss (one bit per > >>> >> segment sent - conveyed more or less accurately > >>> >> by ACKs/SACKs), putting standard ECN feedback into "p" will not= work. > >>> >> > >>> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control= (TFRC)) > >>> >>is used by this solution. So the accuracy of the congestion rate > >>> >>calculation will depend on the accuracy=20 > of the TFRC. Moreover, according > >>> >>to RFC5348: > >>> >> "The throughput equation currently REQUIRED for TFRC is a slightly > >>> >> simplified version of the throughput equation for Reno TCP from > >>> >> [PFTK98]. Ideally, we would prefer a throughput equation based= on > >>> >> selective acknowledgment (SACK) TCP, but no one has yet derived= the > >>> >> throughput equation for SACK TCP, and simulations and= experiments > >>> >> suggest that the differences between the two equations would be > >>> >> relatively minor [FF99] (Appendix B).", from [RFC5348] > >>> >> > >>> >>Furthermore, note that p is the rate of loss events and is depending= on > >>> >>the loss rate. Loss rate measurement is=20 > performed at the receiver, based > >>> >>on the detection of lost or marked packets from the sequence numbers= of > >>> >>arriving packets. > >>> >> > >>> >>p can be send from receiver towards the sender in feedback packets. > >>> >>In TFRC several feedback packets can be sent towards the sender= within > >>> >>one RTT, depending on the sender data rate. > >>> >> > >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> >Furthermore, the congestion volume, if I > >>> >> followed ConEx correctly, is the volume of > >>> >> bytes (measured as IP-layer bytes, NOT IP > >>> >> payload, or TCP payload bytes) which were > >>> >> received with CE set. With only a single bit of > >>> >> feedback per RTT, the congestion volume > >>> >> therefore has a lower bound of PMTU bytes per > >>> >> RTT (actually, the minimum packet size > >>> >> possible, when 1-byte TCP payload segments are > >>> >> sent for whatever reason), and an upper bound > >>> >> of=20 > floor(FlightSize/MSS)+1*(IP_Header+TCP_Header[TCP Options])+FlightSize. > >>> >> > > >>> >> >Your formula would, as it seems to me, always > >>> >> estimate the congestion volume to be close to > >>> >> cwnd/2 (excluding the IP Header, TCP Headers, > >>> >> and also excluding the actual number of > >>> >> congestions during that RTT). This may be a > >>> >> (very) conservative estimate during low > >>> >> congestion periods, but a very aggressive > >>> >> (=3Dmuch too small) estimate during heavy > >>> >> congestion periods (e.g. 1 RTT, where each segment is CE marked). > >>> >> > >>> >>Georgios: As I mentioned the RFC5348 (TCP Friendly Rate Control= (TFRC)) > >>> >>is used by this solution. So the accuracy of the congestion rate > >>> >>calculation will depend on the accuracy of the TFRC. > >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> >Again, the goal for Accurate ECN feedback is > >>> >> to allow an exact (under common circumstances) > >>> >> feedback of the CE marks as seen by a TCP > >>> >> receiver, to be sent back to the sender. As TCP > >>> >> can not rely on external means to enforce > >>> >> honesty (Conex would be one such external > >>> >> means), ECN Nonce support would be beneficial. > >>> >> > >>> >>Georgios: Yes I agree it might be beneficial. > >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> >One more word w.r.t. complexity: I believe > >>> >> that the gap between network performance and > >>> >> CPU performance will not shrink in the future. > >>> >> All developments over the last decade points to > >>> >> an ever widening gap. Therefore, schemes which > >>> >> couldn't be hoped to have any chance to be > >>> >> implemented, because of their complexity, such > >>> >> as Conex, are today running at wirespeed in 10G > >>> >> environments. The times, where one major design > >>> >> goal of a protocol was to use as few as > >>> >> possible machine instructions to > >>> encode/decode and interpret, are long past. > >>> >> > > >>> >> >I have seen early SACK and TS work was > >>> >> discussed in terms of number of machine > >>> >> instructions added to the TCP codepath (which > >>> >> is one piece of the puzzle to understand why > >>> >> timestamp semantics are defined the way they are). > >>> >> > > >>> >> >(Also, calculating the integer square root is > >>> >> more involved than doing some bit-banging ;) > >>> >> > >>> >>Georgios: I think that you refer to my=20 > statement regarding implementation > >>> >>complexity of the Re-ECN solution. The term that I have used is not= the > >>> >>correct one. I should have used deployment complexity instead of > >>> >>implmentation complexity. > >>> >> > >>> >>Best regards, > >>> >>Georgios > >>> >> > >>> >> > >>> >> > > >>> >> > > >>> >> >Richard Scheffenegger > >>> >> > > >>> >> >> -----Original Message----- > >>> >> >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >>> >> >> Sent: Mittwoch, 06. Juli 2011 14:27 > >>> >> >> To: 'Mirja K=FChlewind'; conex@ietf.org > >>> >> >> Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > >>> >> >> > >>> >> >> Hi Mirja > >>> >> >> > >>> >> >> I have (quickly) read the document=20 > draft-kuehlewind-conex-accurate- > >>> >> >> ecn-00. > >>> >> >> So sorry if I have not understood the concept well! > >>> >> >> > >>> >> >> The described solution in this draft is based on [draft-briscoe- > >>> >> >> tsvwg-re-ecn-tcp-09] and is actually used to > >>> >> >> carry the required feedback from the=20 > receiver to the sender such that > >>> >> >> the > >>> >> >> sender could calculate > >>> >> >> the experienced congestion rate (from sender to receiver). > >>> >> >> > >>> >> >> In my opinion this solution being similar to the one proposed in > >>> >> >> [draft-briscoe- tsvwg-re-ecn-tcp-09] > >>> >> >> seems to be quite complex to be=20 > deployed, since protocol changes need > >>> >> >> to be > >>> >> >> accomplished in order to modify the > >>> >> >> semantics of the TCP header, i.e.,=20 > the semantics of the flags: NS, CWR > >>> >> >> and > >>> >> >> ECE. > >>> >> >> > >>> >> >> In > >>> >> >>=20 > http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation- > >>> >> >> 00.txt > >>> >> >> another solution on > >>> >> >> calculating the congestion rate at the sender is described= where > >>> >> >> these > >>> >> >> changes in the semantics of > >>> >> >> TCP are not required. > >>> >> >> > >>> >> >> This document provides a solution to this problem as follows,= see > >>> >> >> Figure 2. in= draft-karagiannis-conex-congestion-calculation-00.txt > >>> >> >> > >>> >> >> When the sender needs to reduce its=20 > sending rate, then the sender can > >>> >> >> calculate the exposed CONGESTION RATE by subtracting the TCP > >>> >> >> throughput calculated during a Round Trip Time (RTT), i.e.,= (RTTi) > >>> >> >> from the TCP throughput calculated=20 > at the same sender side during the > >>> >> >> previous RTT, i.e., (RTTi-1), where=20 > i is an integer equal or higher > >>> >> >> than 1. > >>> >> >> > >>> >> >> The TCP throughput at the sender side=20 > can be calculated using, e.g., > >>> >> >> the following equation specified in [RFC5348]: > >>> >> >> > >>> >> >> > >>> >> >> "The throughput equation for=20 > X_Bps, TCP's average sending rate in > >>> >> >> bytes per second, is: > >>> >> >> > >>> >> >> s > >>> >> >> X_Bps =3D=20 > ---------------------------------------------------------- > >>> >> >> R*sqrt(2*b*p/3) + (t_RTO *=20 > (3*sqrt(3*b*p/8)*p*(1+32*p^2))) > >>> >> >> > >>> >> >> Where: > >>> >> >> > >>> >> >> X_Bps is TCP's average transmit=20 > rate in bytes per second. (X_Bps > >>> >> >> is the same as X_calc in RFC 3448.) > >>> >> >> > >>> >> >> s is the segment size in bytes (excluding IP and transport > >>> >> >> protocol headers). > >>> >> >> > >>> >> >> R is the round-trip time in seconds. > >>> >> >> > >>> >> >> p is the loss event rate, between 0 and 1.0, of the number= of > >>> >> >> loss > >>> >> >> events as a fraction of the number of packets transmitted. > >>> >> >> > >>> >> >> t_RTO is the TCP retransmission timeout value in seconds. > >>> >> >> > >>> >> >> b is the maximum number of=20 > packets acknowledged by a single TCP > >>> >> >> acknowledgement.", copied from [RFC5368]. > >>> >> >> > >>> >> >> > >>> >> >> Note that the transport path throughput calculated at the sender= is > >>> >> >> defined > >>> >> >> as: The per flow transport sending=20 > rate as a function of the congestion > >>> >> >> rate, round-trip time, and segment=20 > size. The transport path throughput > >>> >> >> calculated at the sender using the=20 > TCP throughput equation specified in > >>> >> >> [RFC5348]. Note that in [RFC5348] the=20 > term congestion rate is denoted > >>> >> >> as > >>> >> >> loss event rate. According to=20 > [RFC5348] a loss event is defined as one > >>> >> >> or > >>> >> >> more lost or marked packets from a window of data, where a= marked > >>> >> >> packet > >>> >> >> refers to a congestion indication (CE) from Explicit Congestion > >>> >> >> Notification > >>> >> >> (ECN) [RFC3168]; > >>> >> >> > >>> >> >> Best regards, > >>> >> >> Georgios > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -----Original Message----- > >>> >> >> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]= On > >>> >> >> Behalf > >>> >> >> > Of Mirja K=FChlewind > >>> >> >> > Sent: woensdag 6 juli 2011 10:23 > >>> >> >> > To: conex@ietf.org > >>> >> >> > Subject: [conex] New draft(s) on TCP modifications for ConEx > >>> >> >> > > >>> >> >> > Hello, > >>> >> >> > > >>> >> >> > we submitted two new drafts=20 > regarding the needed TCP modifications > >>> >> >> for > >>> >> >> > ConEx. > >>> >> >> > As ConEx relies (partially) on ECN, a more accurate ECN= feedback > >>> >> >> (more > >>> >> >> than > >>> >> >> > max. one signal per RTT) is needed. The same information would= be > >>> >> >> > valuebale for other currently proposed TCP mechanisms e.g.= DCTCP. > >>> >> >> This is > >>> >> >> > why, we decided to split this=20 > modification into a separate and tried > >>> >> >> to > >>> >> >> specify > >>> >> >> > this independent of ConEx. Thus we have two drafts now: > >>> >> >> > > >>> >> >> > 1. draft-kuehlewind-conex-accurate-ecn > >>> >> >> > This draft currently proposes three different coding scheme to > >>> >> >> realize a > >>> >> >> more > >>> >> >> > accurate ECN feedback. All=20 > approaches use the available 'classic' ECN > >>> >> >> bit > >>> >> >> > space as only one mechanism (classic ECN or the new more= accurate > >>> >> >> scheme) > >>> >> >> > is needed at a time. The goal is to=20 > chose one of the coding options > >>> >> >> and > >>> >> >> have > >>> >> >> > the other option and all=20 > discussions removed at later version of this > >>> >> >> draft. > >>> >> >> > > >>> >> >> > 2. draft-kuehlewind-conex-tcp-modifications > >>> >> >> > This draft describes all other=20 > modifications/recommendations to use > >>> >> >> ConEx > >>> >> >> > with TCP. This is the use of ECN=20 > and SACK and recommendations on the > >>> >> >> > credit bit. > >>> >> >> > This document contains several=20 > points which need further discussion > >>> >> >> e.g. > >>> >> >> the > >>> >> >> > handling and validity of credits. > >>> >> >> > > >>> >> >> > Please have a look at the drafts; Feedback is very welcome! > >>> >> >> > > >>> >> >> > Mirja and Richard > >>> >> >> > >>> >> >> _______________________________________________ > >>> >> >> 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 > >> > >>________________________________________________________________ > >>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 Jul 7 03:06: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 2C2CA21F85C6 for ; Thu, 7 Jul 2011 03:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV7vX1ZKovF1 for ; Thu, 7 Jul 2011 03:06:26 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 22CF321F85B4 for ; Thu, 7 Jul 2011 03:06:25 -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, 7 Jul 2011 11:06: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); Thu, 7 Jul 2011 11:06: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 1310033181715; Thu, 7 Jul 2011 11:06:21 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.194.135]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67A6Jw3025301; Thu, 7 Jul 2011 11:06:20 +0100 Message-Id: <201107071006.p67A6Jw3025301@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 11:06:21 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4E156612.5030409@informatik.uni-tuebingen.de> References: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> <4E156612.5030409@informatik.uni-tuebingen.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_237544911==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 07 Jul 2011 10:06:23.0578 (UTC) FILETIME=[86C16BA0:01CC3C8D] Cc: ConEx IETF list Subject: Re: [conex] Non-goals and/or misconceptions for 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, 07 Jul 2011 10:06:28 -0000 --=====================_237544911==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Michael, inline tagged [BB]: At 08:53 07/07/2011, Michael Menth wrote: >Hi Bob, > >Am 07.07.2011 01:39, schrieb Bob Briscoe: >>John, and all, >> >>To make this concrete, here's some items I could put in conex-concepts-uses. >> >>Some are non-goals. Some are misconceptions. Not in the sense that >>people are wrong about some objective fact. But in the sense that >>they are wrong about what ConEx is trying to say. Ie. >>Misconceptions about ConEx. >> >>All, = please suggest which ones are most important to keep, which >>ones can go, and which ones need clarifying. > >I'd put such a section rather at the end or in the appendix of the >document. Just brief feedback. [BB]: If the reader holds one of these misconceptions, they won't want to read on. The purpose of putting it here was to make them want to read on. I've discovered Matt Mathis (I think?) wrote a really brief para in conex-abstract-mech that says a fair bit of this really succinctly. " There is no expectation that internetwork layer devices will do fine- grained congestion control using ConEx information. That is still probably best done at the transport sender. Rather, the network will be able to use ConEx information to do better bulk traffic management, which in turn should incentivize end-system transports to be more careful about congesting others [I-D.conex-concepts-uses]. " I will try to emulate this, and cover some of the other bullets too, in a couple of similar paras, which would allow the whole doc to flow better: Two requests for clarification inline... >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >>2.2. Common Misconceptions about ConEx >> >> Isn't good provisioning the way to solve congestion, not ConEx? >> This is largely true. However a statement like this contains a >> number of misconceptions about ConEx: >> >> * ConEx is not trying to 'solve' congestion, at least not >> directly. ConEx is about making congestion visible as a useful >> metric. >> >> * Once congestion-based traffic management is in place, the >> operator can set a low congestion threshold to trigger and >> target upgrades to bottlenecks (see Section 5.4). >... can use congestion information to trigger ... > >> >> * Removing congestion completely is a non-goal. If an end-to-end >> transport protocol cannot go fast enough to cause congestion >> somewhere along the path, it is probably broken. So it is >> misleading to selectively point to parts of a network (e.g. the >> core) that are uncongested by design. Application performance >> depends on the bottleneck, which a good transport protocol will >> seek out--typically finding it in the access network (or all >> too often in the receiver's buffer, but that's another story). >> Low levels of congestion somewhere are therefore healthy. >> >> * Congestion and Utilisation are different. Protocols like TCP >> aim to fill a link so the transfer finishes as quickly as >> possible. If a link is 10% utilised on average, this can imply >> it is 100% utilised 10% of the time. Or it might be 10% >> utilised all the time. Averaging utilisation over a few >> minutes hides what happened within the averaging time. In >> contrast, measuring congestion-volume over the same few minutes >> will distinguish between the two cases. >The link to the major point must be better worked out. [BB]: I believe moving the targeted upgrades bullet to last will help the logical flow, but I agree this bullet seems disconnected unless you think hard about it. It doesn't help the reader make the implicit link between provisioning in the major point and utilisation in this bullet. >>Briscoe & Woundy Expires January 5, 2012 [Page 7] >> >>Internet-Draft ConEx Mechanism July 2011 >> >> >> * It is not our place to judge. Many operators choose a mix of >> traffic management and capacity upgrades, whether they run a >> University network or a national ISP. Rather than beating our >> chests about evil traffic management, the idea is to recognise >> it is a legitimate choice, understand why poor practice is >> widespread and enable best practice instead. At the same time >> providing a good metric to support decisions on upgrading >> bottlenecks too. >Hm, difficult. Definitely needs rewording. [BB]: The chest-beating part? Or other parts too? >> Exposing Congestion to what? ConEx is about the sender exposing >> congestion to the network, not the other way round. That would >> not make sense in the context of the TCP/IP protocol suite, >> because the end-systems already detect congestion by design. >> >> Is the idea for IP routers to use this congestion information? No >> (but maybe). The sender puts ConEx information in the IP layer so >> that specific functions can be deployed in the network to use it, >> e.g. traffic management. These functions might be part of an edge >> IP router, but might also be a separate box. Some ideas do exist >> for forwarding on routers to optionally use ConEx (e.g. for >> preferential discard), but that is not the current focus. >> >> Is the idea that network traffic management does congestion control? >> No. The sender is still expected to do congestion control on fast >> timescales. The reason the network needs congestion information >> is not for congestion control, but to arbitrate overall fairness >> at run-time. >The meaning of the last sentence is not fully clear. > >> >> But congestion control does fairness, doesn't it? Not really. >> Congestion control determines the instantaneous shares of some >> bottleneck links (absent network mechanisms like round-robin >> scheduling). But it doesn't determine how much data an >> application transfers, or how many flows it opens, or which >> congestion control algorithm an application uses, or how many >> applications the user runs, or how many users are active at once. >> These factors all determine how great a share of a link is >> available for any particular data transfer. Network operators use >> traffic management to ensure some level of overall fairness given >> all these factors. That's what the congestion information is >> needed for. >Should be dropped or reformulated. [BB]: Many people hold this misconception. I was more pleased with this para than any of the others. What's the problem? >> So you want the network to enforce compliance to the TCP algorithm? >> Emphatically no. Some applications would not work if the network >> forced everything to behave like TCP. This would also prevent >> deployment of higher performance replacements to TCP. The idea of >> ConEx is to only enforce overall bulk limits to congestion. Some >> applications (e.g. short transfers) could be more aggressive than >> TCP. Others (e.g. long transfers) could be less aggressive, >Interesting point, good to mention. Cheers Bob >Regards, > > Michael > >> >> >>Briscoe & Woundy Expires January 5, 2012 [Page 8] >> >> >> >> >> >>________________________________________________________________ >>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 --=====================_237544911==.ALT Content-Type: text/html; charset="us-ascii" Michael,

inline tagged [BB]:

At 08:53 07/07/2011, Michael Menth wrote:
Hi Bob,

Am 07.07.2011 01:39, schrieb Bob Briscoe:
John, and all,

To make this concrete, here's some items I could put in conex-concepts-uses.

Some are non-goals. Some are misconceptions. Not in the sense that people are wrong about some objective fact. But in the sense that they are wrong about what ConEx is trying to say. Ie. Misconceptions about ConEx.

All, = please suggest which ones are most important to keep, which ones can go, and which ones need clarifying.

I'd put such a section rather at the end or in the appendix of the document. Just brief feedback.

[BB]: If the reader holds one of these misconceptions, they won't want to read on. The purpose of putting it here was to make them want to read on.

I've discovered Matt Mathis (I think?) wrote a really brief para in conex-abstract-mech that says a fair bit of this really succinctly.

"
   There is no expectation that internetwork layer devices
will do fine-
   grained congestion control using ConEx information. 
That is still
   probably best done at the transport sender.  Rather,
the network will
   be able to use ConEx information to do better bulk traffic
   management, which in turn should incentivize end-system
transports to
   be more careful about congesting others
[I-D.conex-concepts-uses].
"
I will try to emulate this, and cover some of the other bullets too, in a couple of similar paras, which would allow the whole doc to flow better:

Two requests for clarification inline...



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
2.2.  Common Misconceptions about ConEx

   Isn't good provisioning the way to solve congestion, not ConEx?
      This is largely true.  However a statement like this contains a
      number of misconceptions about ConEx:

      *  ConEx is not trying to 'solve' congestion, at least not
         directly.  ConEx is about making congestion visible as a useful
         metric.

      *  Once congestion-based traffic management is in place, the
         operator can set a low congestion threshold to trigger and
         target upgrades to bottlenecks (see Section 5.4).
... can use congestion information to trigger ...


      *  Removing congestion completely is a non-goal.  If an end-to-end
         transport protocol cannot go fast enough to cause congestion
         somewhere along the path, it is probably broken.  So it is
         misleading to selectively point to parts of a network (e.g. the
         core) that are uncongested by design.  Application performance
         depends on the bottleneck, which a good transport protocol will
         seek out--typically finding it in the access network (or all
         too often in the receiver's buffer, but that's another story).
         Low levels of congestion somewhere are therefore healthy.

      *  Congestion and Utilisation are different.  Protocols like TCP
         aim to fill a link so the transfer finishes as quickly as
         possible.  If a link is 10% utilised on average, this can imply
         it is 100% utilised 10% of the time.  Or it might be 10%
         utilised all the time.  Averaging utilisation over a few
         minutes hides what happened within the averaging time.  In
         contrast, measuring congestion-volume over the same few minutes
         will distinguish between the two cases.
The link to the major point must be better worked out.


[BB]: I believe moving the targeted upgrades bullet to last will help the logical flow, but I agree this bullet seems disconnected unless you think hard about it. It doesn't help the reader make the implicit link between provisioning in the major point and utilisation in this bullet.







Briscoe & Woundy         Expires January 5, 2012                [Page 7]

Internet-Draft               ConEx Mechanism                   July 2011


      *  It is not our place to judge.  Many operators choose a mix of
         traffic management and capacity upgrades, whether they run a
         University network or a national ISP.  Rather than beating our
         chests about evil traffic management, the idea is to recognise
         it is a legitimate choice, understand why poor practice is
         widespread and enable best practice instead.  At the same time
         providing a good metric to support decisions on upgrading
         bottlenecks too.
Hm, difficult. Definitely needs rewording.

[BB]: The chest-beating part? Or other parts too?




   Exposing Congestion to what?  ConEx is about the sender exposing
      congestion to the network, not the other way round.  That would
      not make sense in the context of the TCP/IP protocol suite,
      because the end-systems already detect congestion by design.

   Is the idea for IP routers to use this congestion information?  No
      (but maybe).  The sender puts ConEx information in the IP layer so
      that specific functions can be deployed in the network to use it,
      e.g. traffic management.  These functions might be part of an edge
      IP router, but might also be a separate box.  Some ideas do exist
      for forwarding on routers to optionally use ConEx (e.g. for
      preferential discard), but that is not the current focus.

   Is the idea that network traffic management does congestion control?
      No.  The sender is still expected to do congestion control on fast
      timescales.  The reason the network needs congestion information
      is not for congestion control, but to arbitrate overall fairness
      at run-time.
The meaning of the last sentence is not fully clear.


   But congestion control does fairness, doesn't it?  Not really.
      Congestion control determines the instantaneous shares of some
      bottleneck links (absent network mechanisms like round-robin
      scheduling).  But it doesn't determine how much data an
      application transfers, or how many flows it opens, or which
      congestion control algorithm an application uses, or how many
      applications the user runs, or how many users are active at once.
      These factors all determine how great a share of a link is
      available for any particular data transfer.  Network operators use
      traffic management to ensure some level of overall fairness given
      all these factors.  That's what the congestion information is
      needed for.
Should be dropped or reformulated.

[BB]: Many people hold this misconception. I was more pleased with this para than any of the others. What's the problem?



   So you want the network to enforce compliance to the TCP algorithm?
      Emphatically no.  Some applications would not work if the network
      forced everything to behave like TCP.  This would also prevent
      deployment of higher performance replacements to TCP.  The idea of
      ConEx is to only enforce overall bulk limits to congestion.  Some
      applications (e.g. short transfers) could be more aggressive than
      TCP.  Others (e.g. long transfers) could be less aggressive,
Interesting point, good to mention.

Cheers



Bob




Regards,

    Michael



Briscoe & Woundy         Expires January 5, 2012                [Page 8]





________________________________________________________________
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 --=====================_237544911==.ALT-- From menth@informatik.uni-tuebingen.de Thu Jul 7 03:17: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 A1C2D21F872D for ; Thu, 7 Jul 2011 03:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 oUmAODtQvFo0 for ; Thu, 7 Jul 2011 03:17: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 8B5BA21F84AC for ; Thu, 7 Jul 2011 03:17:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id A0F265296; Thu, 7 Jul 2011 12:17:43 +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 Io8-wpCKwwum; Thu, 7 Jul 2011 12:17:36 +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 9CB6A5263; Thu, 7 Jul 2011 12:17:36 +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 435FA20222AA; Thu, 7 Jul 2011 12:17:36 +0200 (CEST) Message-ID: <4E1587C0.8090906@informatik.uni-tuebingen.de> Date: Thu, 07 Jul 2011 12:17:36 +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: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> <4E156612.5030409@informatik.uni-tuebingen.de> <201107071006.p67A6Jw3025301@bagheera.jungle.bt.co.uk> In-Reply-To: <201107071006.p67A6Jw3025301@bagheera.jungle.bt.co.uk> Content-Type: multipart/alternative; boundary="------------050503020900050004000103" Cc: ConEx IETF list Subject: Re: [conex] Non-goals and/or misconceptions for 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, 07 Jul 2011 10:17:50 -0000 This is a multi-part message in MIME format. --------------050503020900050004000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Bob, Am 07.07.2011 12:06, schrieb Bob Briscoe: > Michael, > > inline tagged [BB]: > > At 08:53 07/07/2011, Michael Menth wrote: >> Hi Bob, >> >> Am 07.07.2011 01:39, schrieb Bob Briscoe: >>> John, and all, >>> >>> To make this concrete, here's some items I could put in >>> conex-concepts-uses. >>> >>> Some are non-goals. Some are misconceptions. Not in the sense that >>> people are wrong about some objective fact. But in the sense that >>> they are wrong about what ConEx is trying to say. Ie. Misconceptions >>> about ConEx. >>> >>> All, = please suggest which ones are most important to keep, which >>> ones can go, and which ones need clarifying. >> >> I'd put such a section rather at the end or in the appendix of the >> document. Just brief feedback. > > [BB]: If the reader holds one of these misconceptions, they won't want > to read on. The purpose of putting it here was to make them want to > read on. > > I've discovered Matt Mathis (I think?) wrote a really brief para in > conex-abstract-mech that says a fair bit of this really succinctly. > > " > There is no expectation that internetwork layer devices > will do fine- > grained congestion control using ConEx information. > That is still > probably best done at the transport sender. Rather, > the network will > be able to use ConEx information to do better bulk traffic > management, which in turn should incentivize end-system > transports to > be more careful about congesting others > [I-D.conex-concepts-uses]. > > " > I will try to emulate this, and cover some of the other bullets too, > in a couple of similar paras, which would allow the whole doc to flow > better: > > Two requests for clarification inline... > > > >>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>> >>> 2.2. Common Misconceptions about ConEx >>> >>> Isn't good provisioning the way to solve congestion, not ConEx? >>> This is largely true. However a statement like this contains a >>> number of misconceptions about ConEx: >>> >>> * ConEx is not trying to 'solve' congestion, at least not >>> directly. ConEx is about making congestion visible as a useful >>> metric. >>> >>> * Once congestion-based traffic management is in place, the >>> operator can set a low congestion threshold to trigger and >>> target upgrades to bottlenecks (see Section 5.4). >> ... can use congestion information to trigger ... >> >>> >>> * Removing congestion completely is a non-goal. If an end-to-end >>> transport protocol cannot go fast enough to cause congestion >>> somewhere along the path, it is probably broken. So it is >>> misleading to selectively point to parts of a network (e.g. the >>> core) that are uncongested by design. Application performance >>> depends on the bottleneck, which a good transport protocol will >>> seek out--typically finding it in the access network (or all >>> too often in the receiver's buffer, but that's another story). >>> Low levels of congestion somewhere are therefore healthy. >>> >>> * Congestion and Utilisation are different. Protocols like TCP >>> aim to fill a link so the transfer finishes as quickly as >>> possible. If a link is 10% utilised on average, this can imply >>> it is 100% utilised 10% of the time. Or it might be 10% >>> utilised all the time. Averaging utilisation over a few >>> minutes hides what happened within the averaging time. In >>> contrast, measuring congestion-volume over the same few minutes >>> will distinguish between the two cases. >> The link to the major point must be better worked out. > > > [BB]: I believe moving the targeted upgrades bullet to last will help > the logical flow, but I agree this bullet seems disconnected unless > you think hard about it. It doesn't help the reader make the implicit > link between provisioning in the major point and utilisation in this > bullet. > > > > > > > >>> Briscoe & Woundy Expires January 5, 2012 [Page 7] >>> >>> Internet-Draft ConEx Mechanism July 2011 >>> >>> >>> * It is not our place to judge. Many operators choose a mix of >>> traffic management and capacity upgrades, whether they run a >>> University network or a national ISP. Rather than beating our >>> chests about evil traffic management, the idea is to recognise >>> it is a legitimate choice, understand why poor practice is >>> widespread and enable best practice instead. At the same time >>> providing a good metric to support decisions on upgrading >>> bottlenecks too. >> Hm, difficult. Definitely needs rewording. > > [BB]: The chest-beating part? Or other parts too? I do not see what this has to do with misconceptions. Essentially it's the motivation for conex that was already mentioned in the introduction. > > > > >>> Exposing Congestion to what? ConEx is about the sender exposing >>> congestion to the network, not the other way round. That would >>> not make sense in the context of the TCP/IP protocol suite, >>> because the end-systems already detect congestion by design. >>> >>> Is the idea for IP routers to use this congestion information? No >>> (but maybe). The sender puts ConEx information in the IP layer so >>> that specific functions can be deployed in the network to use it, >>> e.g. traffic management. These functions might be part of an edge >>> IP router, but might also be a separate box. Some ideas do exist >>> for forwarding on routers to optionally use ConEx (e.g. for >>> preferential discard), but that is not the current focus. >>> >>> Is the idea that network traffic management does congestion control? >>> No. The sender is still expected to do congestion control on fast >>> timescales. The reason the network needs congestion information >>> is not for congestion control, but to arbitrate overall fairness >>> at run-time. >> The meaning of the last sentence is not fully clear. >> >>> >>> But congestion control does fairness, doesn't it? Not really. >>> Congestion control determines the instantaneous shares of some >>> bottleneck links (absent network mechanisms like round-robin >>> scheduling). But it doesn't determine how much data an >>> application transfers, or how many flows it opens, or which >>> congestion control algorithm an application uses, or how many >>> applications the user runs, or how many users are active at once. >>> These factors all determine how great a share of a link is >>> available for any particular data transfer. Network operators use >>> traffic management to ensure some level of overall fairness given >>> all these factors. That's what the congestion information is >>> needed for. >> Should be dropped or reformulated. > > [BB]: Many people hold this misconception. I was more pleased with > this para than any of the others. What's the problem? You probably want to say that congestion control approximates per flow fairness but that's not what network operators want. They want parameterizable per-user fairness. The former is easy to achieve and what we currently have in the Internet. The latter is hard to achieve in a flexible way without congestion information. That's why we need conex. Right? Regards, Michael > > > >>> So you want the network to enforce compliance to the TCP algorithm? >>> Emphatically no. Some applications would not work if the network >>> forced everything to behave like TCP. This would also prevent >>> deployment of higher performance replacements to TCP. The idea of >>> ConEx is to only enforce overall bulk limits to congestion. Some >>> applications (e.g. short transfers) could be more aggressive than >>> TCP. Others (e.g. long transfers) could be less aggressive, >> Interesting point, good to mention. > > Cheers > > > > Bob > > > > >> Regards, >> >> Michael >> >>> >>> >>> Briscoe & Woundy Expires January 5, 2012 [Page 8] >>> >>> >>> >>> >>> >>> ________________________________________________________________ >>> 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 --------------050503020900050004000103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Bob,

Am 07.07.2011 12:06, schrieb Bob Briscoe:

Michael,

inline tagged [BB]:

At 08:53 07/07/2011, Michael Menth wrote:
Hi Bob,

Am 07.07.2011 01:39, schrieb Bob Briscoe:
John, and all,

To make this concrete, here's some items I could put in conex-concepts-uses.

Some are non-goals. Some are misconceptions. Not in the sense that people are wrong about some objective fact. But in the sense that they are wrong about what ConEx is trying to say. Ie. Misconceptions about ConEx.

All, = please suggest which ones are most important to keep, which ones can go, and which ones need clarifying.

I'd put such a section rather at the end or in the appendix of the document. Just brief feedback.

[BB]: If the reader holds one of these misconceptions, they won't want to read on. The purpose of putting it here was to make them want to read on.

I've discovered Matt Mathis (I think?) wrote a really brief para in conex-abstract-mech that says a fair bit of this really succinctly.

"
   There is no expectation that internetwork layer devices
will do fine-
   grained congestion control using ConEx information. 
That is still
   probably best done at the transport sender.  Rather,
the network will
   be able to use ConEx information to do better bulk traffic
   management, which in turn should incentivize end-system
transports to
   be more careful about congesting others
[I-D.conex-concepts-uses].
"
I will try to emulate this, and cover some of the other bullets too, in a couple of similar paras, which would allow the whole doc to flow better:

Two requests for clarification inline...



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
2.2.  Common Misconceptions about ConEx

   Isn't good provisioning the way to solve congestion, not ConEx?
      This is largely true.  However a statement like this contains a
      number of misconceptions about ConEx:

      *  ConEx is not trying to 'solve' congestion, at least not
         directly.  ConEx is about making congestion visible as a useful
         metric.

      *  Once congestion-based traffic management is in place, the
         operator can set a low congestion threshold to trigger and
         target upgrades to bottlenecks (see Section 5.4).
... can use congestion information to trigger ...


      *  Removing congestion completely is a non-goal.  If an end-to-end
         transport protocol cannot go fast enough to cause congestion
         somewhere along the path, it is probably broken.  So it is
         misleading to selectively point to parts of a network (e.g. the
         core) that are uncongested by design.  Application performance
         depends on the bottleneck, which a good transport protocol will
         seek out--typically finding it in the access network (or all
         too often in the receiver's buffer, but that's another story).
         Low levels of congestion somewhere are therefore healthy.

      *  Congestion and Utilisation are different.  Protocols like TCP
         aim to fill a link so the transfer finishes as quickly as
         possible.  If a link is 10% utilised on average, this can imply
         it is 100% utilised 10% of the time.  Or it might be 10%
         utilised all the time.  Averaging utilisation over a few
         minutes hides what happened within the averaging time.  In
         contrast, measuring congestion-volume over the same few minutes
         will distinguish between the two cases.
The link to the major point must be better worked out.


[BB]: I believe moving the targeted upgrades bullet to last will help the logical flow, but I agree this bullet seems disconnected unless you think hard about it. It doesn't help the reader make the implicit link between provisioning in the major point and utilisation in this bullet.







Briscoe & Woundy         Expires January 5, 2012                [Page 7]

Internet-Draft               ConEx Mechanism                   July 2011


      *  It is not our place to judge.  Many operators choose a mix of
         traffic management and capacity upgrades, whether they run a
         University network or a national ISP.  Rather than beating our
         chests about evil traffic management, the idea is to recognise
         it is a legitimate choice, understand why poor practice is
         widespread and enable best practice instead.  At the same time
         providing a good metric to support decisions on upgrading
         bottlenecks too.
Hm, difficult. Definitely needs rewording.

[BB]: The chest-beating part? Or other parts too?
I do not see what this has to do with misconceptions. Essentially it's the motivation for conex that was already mentioned in the introduction.






   Exposing Congestion to what?  ConEx is about the sender exposing
      congestion to the network, not the other way round.  That would
      not make sense in the context of the TCP/IP protocol suite,
      because the end-systems already detect congestion by design.

   Is the idea for IP routers to use this congestion information?  No
      (but maybe).  The sender puts ConEx information in the IP layer so
      that specific functions can be deployed in the network to use it,
      e.g. traffic management.  These functions might be part of an edge
      IP router, but might also be a separate box.  Some ideas do exist
      for forwarding on routers to optionally use ConEx (e.g. for
      preferential discard), but that is not the current focus.

   Is the idea that network traffic management does congestion control?
      No.  The sender is still expected to do congestion control on fast
      timescales.  The reason the network needs congestion information
      is not for congestion control, but to arbitrate overall fairness
      at run-time.
The meaning of the last sentence is not fully clear.


   But congestion control does fairness, doesn't it?  Not really.
      Congestion control determines the instantaneous shares of some
      bottleneck links (absent network mechanisms like round-robin
      scheduling).  But it doesn't determine how much data an
      application transfers, or how many flows it opens, or which
      congestion control algorithm an application uses, or how many
      applications the user runs, or how many users are active at once.
      These factors all determine how great a share of a link is
      available for any particular data transfer.  Network operators use
      traffic management to ensure some level of overall fairness given
      all these factors.  That's what the congestion information is
      needed for.
Should be dropped or reformulated.

[BB]: Many people hold this misconception. I was more pleased with this para than any of the others. What's the problem?

You probably want to say that congestion control approximates per flow fairness but that's not what network operators want. They want parameterizable per-user fairness. The former is easy to achieve and what we currently have in the Internet. The latter is hard to achieve in a flexible way without congestion information. That's why we need conex. Right?

Regards,

    Michael




   So you want the network to enforce compliance to the TCP algorithm?
      Emphatically no.  Some applications would not work if the network
      forced everything to behave like TCP.  This would also prevent
      deployment of higher performance replacements to TCP.  The idea of
      ConEx is to only enforce overall bulk limits to congestion.  Some
      applications (e.g. short transfers) could be more aggressive than
      TCP.  Others (e.g. long transfers) could be less aggressive,
Interesting point, good to mention.

Cheers



Bob




Regards,

    Michael



Briscoe & Woundy         Expires January 5, 2012                [Page 8]





________________________________________________________________
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
--------------050503020900050004000103-- From karagian@cs.utwente.nl Thu Jul 7 03:50: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 BF24021F87E3 for ; Thu, 7 Jul 2011 03:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 JZy2bnvG6asX for ; Thu, 7 Jul 2011 03:50:47 -0700 (PDT) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by ietfa.amsl.com (Postfix) with ESMTP id A333621F87E2 for ; Thu, 7 Jul 2011 03:50:46 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p67AoVSK014584; Thu, 7 Jul 2011 12:50:31 +0200 From: "Georgios Karagiannis" To: "'Bob Briscoe'" References: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> In-Reply-To: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> Date: Thu, 7 Jul 2011 12:50:31 +0200 Message-ID: <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGa0yk5C+jAK1WHfjhtu1emGlhaagJ5+/49A0Hqez6VFY+j4A== Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: conex@ietf.org Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 10:50:48 -0000 Hi Bob, Please see in line! > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: donderdag 7 juli 2011 11:28 > To: Georgios Karagiannis > Cc: conex@ietf.org > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > Georgios, > > >On 7/7/2011, "Georgios Karagiannis" wrote: > > >Regarding the beyond reasoning statement, it is better to not discuss > > >it via email, but face to face. Will you be in Quebec during the next > > >IETF meeting? > > I meant that your response was not engaging in the reasoning put to you. > > You can go back and respond to the reasoning already given. But I don't need > to say any more. > > My main point was that the whole idea of your draft goes round in a loop > that achieves nothing. > You avoided this critical point and jumped to a detail (a detail within that loop > that already achieves nothing). Georgios: I am not sure if this loop applies to what is written in my draft. > > Now you are saying you meant something very different to what you had > written (you now say the draft was about DCCP, but the title of your draft > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP takes you off- > charter instead (see below). In the drafts I had not yet specified which transport protocol should be used, what I have specified was that the congestion exposure can be calculated using the TCP throughput formula used in TFRC (RFC5348). And according to [RFC5348] "TFRC is a congestion control mechanism designed for unicast flows operating in an Internet environment and competing with TCP traffic [FHPW00]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as DCCP (Datagram Congestion Control Protocol) [RFC4340], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [BRS99].", from [RFC5348]. So I do not think that I was saying something in the previous email that is different than what is stated in my draft. > > At 07:08 07/07/2011, Georgios Karagiannis wrote: > >Do you mean that is off-charter because is using for feedback DCCP & > >TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? > > Yes. > > ConEx is primarily at the IP layer, but some transports need optional changes > to their feedback. The charter says we will focus on TCP first. Georgios: In the charter the following is mentioned: "Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements. The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, be provided as input to traffic management." , from [Conex charter] Further down the charter mentions: "Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender.", from [Conex charter] By reading the first paragraph from above, I can understand that Conex WG will use transport-layer acknowledgement to pass the congestion information (signalled by ECN markings or by dropping packets to the receiver) from the receiver to the sender. Thus any types of transport protocols can be used for this purpose (e.g., TCP, DCCP). By reading the third bullet from above, I can understand that the CONEX WG will primarily focus on TCP. However, to my understanding this does not imply that other types of transport protocols, e.g. ., DCCP, are off-charter. This is in my opinion not explicitly mentioned in the charter. Could the WG chairs comment on this issues, see below: Conex needs transport protocols to carry congestion information from a receiver to a sender. Are transport protocols such as DCCP out of the Conex charter scope? > > You are criticising a draft written to satisfy this charter objective. You are > saying it is difficult to change the semantics of TCP header fields (which we > are already chartered to do). So you propose everyone should have to use > DCCP in order to use ConEx. That would require every application in the > world that uses TCP to be changed to call DCCP instead, in order to use > ConEx. And most middleboxes (NATs, firewalls) would have to be changed > too. Georgios: Sorry Bob, but this is your interpretation. Another interpretation could be: It is good to provide the means such that Conex is used in combination with applications that are using not only TCP as a transport protocol, but also the ones that are using DCCP as transport protocol. Furthermore, start with a solution to calculate congestion, in this case the TFRC [RF5348], that is simple and does not imply many standardization changes on the transport protocols using this solution. Moreover, note that I am in favour that a TCP based transport solution should be specified in parallel. Best regards, Georgios From bob.briscoe@bt.com Thu Jul 7 04:07: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 A303521F8778 for ; Thu, 7 Jul 2011 04:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 QSLbd2s4VFBo for ; Thu, 7 Jul 2011 04:07: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 C1C6C21F877C for ; Thu, 7 Jul 2011 04:07:22 -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, 7 Jul 2011 12:07:20 +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, 7 Jul 2011 12:07:19 +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 1310036838160; Thu, 7 Jul 2011 12:07:18 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.194.135]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67B7Hdg025522; Thu, 7 Jul 2011 12:07:17 +0100 Message-Id: <201107071107.p67B7Hdg025522@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 12:07:19 +0100 To: Michael Menth From: Bob Briscoe In-Reply-To: <4E1587C0.8090906@informatik.uni-tuebingen.de> References: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> <4E156612.5030409@informatik.uni-tuebingen.de> <201107071006.p67A6Jw3025301@bagheera.jungle.bt.co.uk> <4E1587C0.8090906@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: 07 Jul 2011 11:07:19.0695 (UTC) FILETIME=[09F899F0:01CC3C96] Cc: ConEx IETF list Subject: Re: [conex] Non-goals and/or misconceptions for 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, 07 Jul 2011 11:07:23 -0000 Michael, At 11:17 07/07/2011, Michael Menth wrote: >Hi Bob, > >Am 07.07.2011 12:06, schrieb Bob Briscoe: >>Michael, >> >>inline tagged [BB]: >> >>At 08:53 07/07/2011, Michael Menth wrote: >>>Hi Bob, >>> >>>Am 07.07.2011 01:39, schrieb Bob Briscoe: >>>>John, and all, >>>> >>>> * It is not our place to judge. Many operators choose a mix of >>>> traffic management and capacity upgrades, whether they run a >>>> University network or a national ISP. Rather than beating our >>>> chests about evil traffic management, the idea is to recognise >>>> it is a legitimate choice, understand why poor practice is >>>> widespread and enable best practice instead. At the same time >>>> providing a good metric to support decisions on upgrading >>>> bottlenecks too. >>>Hm, difficult. Definitely needs rewording. >> >>[BB]: The chest-beating part? Or other parts too? >I do not see what this has to do with misconceptions. Essentially >it's the motivation for conex that was already mentioned in the introduction. [BB2]: Good point. It's deleted (actually saved as possible conclusion text). >>>> But congestion control does fairness, doesn't it? Not really. >>>> Congestion control determines the instantaneous shares of some >>>> bottleneck links (absent network mechanisms like round-robin >>>> scheduling). But it doesn't determine how much data an >>>> application transfers, or how many flows it opens, or which >>>> congestion control algorithm an application uses, or how many >>>> applications the user runs, or how many users are active at once. >>>> These factors all determine how great a share of a link is >>>> available for any particular data transfer. Network operators use >>>> traffic management to ensure some level of overall fairness given >>>> all these factors. That's what the congestion information is >>>> needed for. >>>Should be dropped or reformulated. >> >>[BB]: Many people hold this misconception. I was more pleased with >>this para than any of the others. What's the problem? > >You probably want to say that congestion control approximates per >flow fairness but that's not what network operators want. They want >parameterizable per-user fairness. The former is easy to achieve and >what we currently have in the Internet. The latter is hard to >achieve in a flexible way without congestion information. That's why >we need conex. [BB2]: Now you're making too big a jump for the reader (which I usually do and you point out). My proposed text was carrying the reader across that jump, to see how different the two are. > Right? [BB2]: Right. And the latter encourages the former to become unequal itself (voluntarily and otherwise by force). Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rs@netapp.com Thu Jul 7 04:56: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 B8D7121F877D for ; Thu, 7 Jul 2011 04:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 G4vLRVQMmYoY for ; Thu, 7 Jul 2011 04:56:39 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1221F85C5 for ; Thu, 7 Jul 2011 04:56:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,493,1304319600"; d="scan'208";a="253620060" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 07 Jul 2011 04:56:37 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p67Buahx022542; Thu, 7 Jul 2011 04:56:37 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jul 2011 12:56: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 12:56:15 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E349D@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] New draft(s) on TCP modifications for ConEx Thread-Index: AQGa0yk5C+jAK1WHfjhtu1emGlhaagJ5+/49A0Hqez6VFY+j4IAAHkIw References: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> From: "Scheffenegger, Richard" To: "Georgios Karagiannis" , "Bob Briscoe" X-OriginalArrivalTime: 07 Jul 2011 11:56:36.0992 (UTC) FILETIME=[ECA85000:01CC3C9C] Cc: conex@ietf.org Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 11:56:40 -0000 Hi Georgios, If you choose to use formulas to estimate the transport rate, that = formula obviously has to apply to the transport protocol used. TFRC is = applicable to DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. = However, all bets are off for *ANY* other transport (CBR VoIP over UDP / = RTP). Furthermore, each of these transports has to have some form of feedback = mechanism from the receiver to the sender, so that the sender can = actually react to congestion. Thus, your scheme is implicitly completely = reliant on whatever feedback is available from the transport. RTP, for example, will have very extensive feedback (much more extensive = than what TCP, SCTP, DCCP can do) - see = http://tools.ietf.org/id/draft-ietf-avtcore-ecn-for-rtp-00.txt What Bob tried to point out is exactly that - your method applies a = specific, post-hoc method. This method implicitly relies on transport = feedback already, but then simply appears to stuff all transports into a = TCP-friendly corset, which may not applicable at all. The goal of our drafts (accurate-ecn and conex-tcp-mods) is to address = the critical part, where the transport receiver gives the *appropriate* = (not some estimated) congestion information back to the transport = sender. With TCP, we are unfortunately very constrained due to the very = widespread use (and also because TCP processing is poured into hardware = these days), which severly limits what can be done in a = backwards-compatible way. Best regards, Richard Scheffenegger NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=A0=A0 EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Donnerstag, 07. Juli 2011 12:51 > To: 'Bob Briscoe' > Cc: conex@ietf.org > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hi Bob, >=20 >=20 > Please see in line! >=20 >=20 > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: donderdag 7 juli 2011 11:28 > > To: Georgios Karagiannis > > Cc: conex@ietf.org > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > Georgios, > > > > >On 7/7/2011, "Georgios Karagiannis" wrote: > > > >Regarding the beyond reasoning statement, it is better to not > discuss > > > >it via email, but face to face. Will you be in Quebec during the > next > > > >IETF meeting? > > > > I meant that your response was not engaging in the reasoning put to > you. > > > > You can go back and respond to the reasoning already given. But I > don't > need > > to say any more. > > > > My main point was that the whole idea of your draft goes round in a > loop > > that achieves nothing. > > You avoided this critical point and jumped to a detail (a detail > within > that loop > > that already achieves nothing). >=20 > Georgios: I am not sure if this loop applies to what is written in my > draft. >=20 > > > > Now you are saying you meant something very different to what you = had > > written (you now say the draft was about DCCP, but the title of your > draft > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP takes > you > off- > > charter instead (see below). >=20 > In the drafts I had not yet specified which transport protocol should > be > used, what I have specified was that the congestion exposure > can be calculated using the TCP throughput formula used in TFRC > (RFC5348). > And according to [RFC5348] "TFRC is a congestion control mechanism > designed > for unicast flows operating in > an Internet environment and competing with TCP traffic [FHPW00]. > Instead of specifying a complete protocol, this document simply > specifies a congestion control mechanism that could be used in a > transport protocol such as DCCP (Datagram Congestion Control > Protocol) [RFC4340], in an application incorporating end-to-end > congestion control at the application level, or in the context of > endpoint congestion management [BRS99].", from [RFC5348]. >=20 > So I do not think that I was saying something in the previous email > that is > different than what is stated in my draft. >=20 >=20 > > > > At 07:08 07/07/2011, Georgios Karagiannis wrote: > > >Do you mean that is off-charter because is using for feedback DCCP = & > > >TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? > > > > Yes. > > > > ConEx is primarily at the IP layer, but some transports need = optional > changes > > to their feedback. The charter says we will focus on TCP first. >=20 > Georgios: In the charter the following is mentioned: > "Today, the network may signal > congestion by ECN markings or by dropping packets, and the receiver > passes this information back to the sender in transport-layer > acknowledgements. The mechanism to be developed by the CONEX WG > will enable the sender to also relay the congestion information > back into the network in-band at the IP layer, such that the total > level of congestion is visible to all IP devices along the path, > from where it could, for example, be provided as input to traffic > management." , from [Conex charter] >=20 >=20 > Further down the charter mentions: >=20 > "Primary work items are: >=20 > * An Informational document containing an abstract description of > the congestion exposure mechanism that is independent of specific > transport protocols and congestion information encoding techniques > needed for different IP protocol versions. >=20 > * An Experimental specification of an IPv6 packet structure that > encapsulates CONEX information, defining a packet format and an > interpretation. >=20 >=20 > * An Experimental specification of a modification to TCP, for the > timely transport of congestion information from the destination to > the sender.", from [Conex charter] >=20 >=20 > By reading the first paragraph from above, I can understand that = Conex > WG > will use > transport-layer acknowledgement to pass the congestion information > (signalled by > ECN markings or by dropping packets to the receiver) from the receiver > to > the sender. > Thus any types of transport protocols can be used for this purpose > (e.g., > TCP, DCCP). >=20 >=20 > By reading the third bullet from above, I can understand that the > CONEX WG > will primarily focus on TCP. >=20 > However, to my understanding this does not imply that other types of > transport protocols, e.g. ., DCCP, > are off-charter. This is in my opinion not explicitly mentioned in > the > charter. >=20 > Could the WG chairs comment on this issues, see below: >=20 > Conex needs transport protocols to carry congestion information from a > receiver to a sender. > Are transport protocols such as DCCP out of the Conex charter scope? >=20 > > > > You are criticising a draft written to satisfy this charter > objective. You > are > > saying it is difficult to change the semantics of TCP header fields > (which > we > > are already chartered to do). So you propose everyone should have to > use > > DCCP in order to use ConEx. That would require every application in > the > > world that uses TCP to be changed to call DCCP instead, in order to > use > > ConEx. And most middleboxes (NATs, firewalls) would have to be > changed > > too. >=20 > Georgios: Sorry Bob, but this is your interpretation. >=20 > Another interpretation could be: > It is good to provide the means such that Conex is used in combination > with > applications that are using not only TCP as a transport protocol, > but also the ones that are using DCCP as transport protocol. > Furthermore, start with a solution to calculate congestion, in this > case > the TFRC [RF5348], that is simple and does not imply many > standardization > changes on the transport protocols using this solution. > Moreover, note that I am in favour that a TCP based transport solution > should be specified in parallel. >=20 > Best regards, > Georgios >=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Thu Jul 7 05:07: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 6A9AB9E800A for ; Thu, 7 Jul 2011 05:07:21 -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 snPZ8IQGg+jZ for ; Thu, 7 Jul 2011 05:07:20 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id F09FA9E8009 for ; Thu, 7 Jul 2011 05:07:15 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 394A4759878; Thu, 7 Jul 2011 14:07:14 +0200 (CEST) Message-ID: <4E15A171.7070205@it.uc3m.es> Date: Thu, 07 Jul 2011 14:07:13 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: 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.8.0.1017-18244.007 Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 12:07:21 -0000 Hi Georgios, Could you clarify to me if these drafts fit in our current charter and how? (just to be clear, we can have presentations that don't fit in our charter, but it is importnat to understand what the purpose of the docuemnt is) Regards, marcelo El 06/07/11 21:52, Georgios Karagiannis escribió: > Hi Marcelo, > > Is it possible to get a 10 minutes agenda slot for each of the two below > dafts: > > http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion-calculation/ > > http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01.txt > > Best regards, > Georgios > > > > > On 7/6/2011, "marcelo bagnulo braun" wrote: > >> The draft agenda is posted. >> http://www.ietf.org/proceedings/81/agenda/conex.txt >> Let me know if there are changes. >> Regards, marcelo >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Thu Jul 7 05:10: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 348EC21F85AF for ; Thu, 7 Jul 2011 05:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 mtq2T78YciYe for ; Thu, 7 Jul 2011 05:10:30 -0700 (PDT) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA621F85B0 for ; Thu, 7 Jul 2011 05:10:29 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p67C9xZn027848; Thu, 7 Jul 2011 14:09:59 +0200 From: "Georgios Karagiannis" To: "'Scheffenegger, Richard'" , "'Bob Briscoe'" References: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> <5FDC413D5FA246468C200652D63E627A0F1E349D@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F1E349D@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 7 Jul 2011 14:09:59 +0200 Message-ID: <008e01cc3c9e$cb32dfb0$61989f10$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGa0yk5C+jAK1WHfjhtu1emGlhaagJ5+/49A0Hqez4BmZ7r1AGaZDhelPwVLGA= Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: conex@ietf.org Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 12:10:31 -0000 Hi Richard, You are right! The solution described in my draft only applies to = transport protocols that are using TFRC . So my proposal is: Is it possible to combine our solutions, such that TCP based = applications, but also DCCP based applications can use Conex? Best regards, Georgios > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com] > Sent: donderdag 7 juli 2011 13:56 > To: Georgios Karagiannis; Bob Briscoe > Cc: conex@ietf.org > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hi Georgios, >=20 >=20 > If you choose to use formulas to estimate the transport rate, that = formula > obviously has to apply to the transport protocol used. TFRC is = applicable to > DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. However, all = bets > are off for *ANY* other transport (CBR VoIP over UDP / RTP). >=20 > Furthermore, each of these transports has to have some form of = feedback > mechanism from the receiver to the sender, so that the sender can = actually > react to congestion. Thus, your scheme is implicitly completely = reliant on > whatever feedback is available from the transport. >=20 > RTP, for example, will have very extensive feedback (much more = extensive > than what TCP, SCTP, DCCP can do) - see http://tools.ietf.org/id/draft-ietf- > avtcore-ecn-for-rtp-00.txt >=20 >=20 > What Bob tried to point out is exactly that - your method applies a specific, > post-hoc method. This method implicitly relies on transport feedback > already, but then simply appears to stuff all transports into a TCP-friendly > corset, which may not applicable at all. >=20 >=20 > The goal of our drafts (accurate-ecn and conex-tcp-mods) is to address = the > critical part, where the transport receiver gives the *appropriate* = (not some > estimated) congestion information back to the transport sender. With = TCP, > we are unfortunately very constrained due to the very widespread use = (and > also because TCP processing is poured into hardware these days), which > severly limits what can be done in a backwards-compatible way. >=20 > Best regards, >=20 > Richard Scheffenegger >=20 > NetApp > rs@netapp.com > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com >=20 > EURO PLAZA > Geb=E4ude G, Stiege 7, 3.OG > Am Euro Platz 2 > A-1120 Wien >=20 >=20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Donnerstag, 07. Juli 2011 12:51 > > To: 'Bob Briscoe' > > Cc: conex@ietf.org > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > Hi Bob, > > > > > > Please see in line! > > > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > Sent: donderdag 7 juli 2011 11:28 > > > To: Georgios Karagiannis > > > Cc: conex@ietf.org > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > > > Georgios, > > > > > > >On 7/7/2011, "Georgios Karagiannis" = wrote: > > > > >Regarding the beyond reasoning statement, it is better to not > > discuss > > > > >it via email, but face to face. Will you be in Quebec during = the > > next > > > > >IETF meeting? > > > > > > I meant that your response was not engaging in the reasoning put = to > > you. > > > > > > You can go back and respond to the reasoning already given. But I > > don't > > need > > > to say any more. > > > > > > My main point was that the whole idea of your draft goes round in = a > > loop > > > that achieves nothing. > > > You avoided this critical point and jumped to a detail (a detail > > within > > that loop > > > that already achieves nothing). > > > > Georgios: I am not sure if this loop applies to what is written in = my > > draft. > > > > > > > > Now you are saying you meant something very different to what you > > > had written (you now say the draft was about DCCP, but the title = of > > > your > > draft > > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP takes > > you > > off- > > > charter instead (see below). > > > > In the drafts I had not yet specified which transport protocol = should > > be used, what I have specified was that the congestion exposure can = be > > calculated using the TCP throughput formula used in TFRC (RFC5348). > > And according to [RFC5348] "TFRC is a congestion control mechanism > > designed for unicast flows operating in > > an Internet environment and competing with TCP traffic [FHPW00]. > > Instead of specifying a complete protocol, this document simply > > specifies a congestion control mechanism that could be used in a > > transport protocol such as DCCP (Datagram Congestion Control > > Protocol) [RFC4340], in an application incorporating end-to-end > > congestion control at the application level, or in the context of > > endpoint congestion management [BRS99].", from [RFC5348]. > > > > So I do not think that I was saying something in the previous email > > that is different than what is stated in my draft. > > > > > > > > > > At 07:08 07/07/2011, Georgios Karagiannis wrote: > > > >Do you mean that is off-charter because is using for feedback = DCCP > > > >& TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? > > > > > > Yes. > > > > > > ConEx is primarily at the IP layer, but some transports need > > > optional > > changes > > > to their feedback. The charter says we will focus on TCP first. > > > > Georgios: In the charter the following is mentioned: > > "Today, the network may signal > > congestion by ECN markings or by dropping packets, and the receiver > > passes this information back to the sender in transport-layer > > acknowledgements. The mechanism to be developed by the CONEX WG > will > > enable the sender to also relay the congestion information back into > > the network in-band at the IP layer, such that the total level of > > congestion is visible to all IP devices along the path, from where = it > > could, for example, be provided as input to traffic management." , > > from [Conex charter] > > > > > > Further down the charter mentions: > > > > "Primary work items are: > > > > * An Informational document containing an abstract description of = the > > congestion exposure mechanism that is independent of specific > > transport protocols and congestion information encoding techniques > > needed for different IP protocol versions. > > > > * An Experimental specification of an IPv6 packet structure that > > encapsulates CONEX information, defining a packet format and an > > interpretation. > > > > > > * An Experimental specification of a modification to TCP, for the > > timely transport of congestion information from the destination to = the > > sender.", from [Conex charter] > > > > > > By reading the first paragraph from above, I can understand that > > Conex WG will use transport-layer acknowledgement to pass the > > congestion information (signalled by ECN markings or by dropping > > packets to the receiver) from the receiver to the sender. > > Thus any types of transport protocols can be used for this purpose > > (e.g., TCP, DCCP). > > > > > > By reading the third bullet from above, I can understand that the > > CONEX WG will primarily focus on TCP. > > > > However, to my understanding this does not imply that other types of > > transport protocols, e.g. ., DCCP, are off-charter. This is in my > > opinion not explicitly mentioned in the charter. > > > > Could the WG chairs comment on this issues, see below: > > > > Conex needs transport protocols to carry congestion information from = a > > receiver to a sender. > > Are transport protocols such as DCCP out of the Conex charter scope? > > > > > > > > You are criticising a draft written to satisfy this charter > > objective. You > > are > > > saying it is difficult to change the semantics of TCP header = fields > > (which > > we > > > are already chartered to do). So you propose everyone should have = to > > use > > > DCCP in order to use ConEx. That would require every application = in > > the > > > world that uses TCP to be changed to call DCCP instead, in order = to > > use > > > ConEx. And most middleboxes (NATs, firewalls) would have to be > > changed > > > too. > > > > Georgios: Sorry Bob, but this is your interpretation. > > > > Another interpretation could be: > > It is good to provide the means such that Conex is used in = combination > > with applications that are using not only TCP as a transport = protocol, > > but also the ones that are using DCCP as transport protocol. > > Furthermore, start with a solution to calculate congestion, in this > > case the TFRC [RF5348], that is simple and does not imply many > > standardization changes on the transport protocols using this > > solution. > > Moreover, note that I am in favour that a TCP based transport = solution > > should be specified in parallel. > > > > Best regards, > > Georgios > > > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex From carlberg@g11.org.uk Thu Jul 7 05:27: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 CB3F121F86B9 for ; Thu, 7 Jul 2011 05:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFKl153nrc5n for ; Thu, 7 Jul 2011 05:27:30 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9496021F8530 for ; Thu, 7 Jul 2011 05:27:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=VrOU5xAhNxh03iX0K0ci47hi7S0nVw8L5g8ZDHEJZjBD1qtNDk3+EM/Kn1LwDo01MJMXPvew/k7WZM/O1ZNcUshQa9x9Mu1jWjZSJhc1Qxvf33685E8yPUdN8roh4RsB; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49781 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Qenft-0000iC-Eq; Thu, 07 Jul 2011 12:27:21 +0000 From: ken carlberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 08:27:25 -0400 Message-Id: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.uk> To: "Scheffenegger, Richard" , Mirja Kuehlewind Mime-Version: 1.0 (Apple Message framework v1084) 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: [conex] draft-kuehlewind-conex-accurate-ecn-00 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, 07 Jul 2011 12:27:31 -0000 Hi, I briefly read over the draft and came up with a few initial impressions = (in no particular order)... 1) i think the draft would be improved if there were some explicit = subsections that shouted out to the reader "strengths" and "weaknesses" = of each approach. Section 3.1.5 gives a brief hint of what the reader = should consider, and each of the first three sections has a = "discussion". But in reading the various approaches, I have to dig = around and write on a separate paper what characteristics I need to be = aware of in comparing one to the other. I see that you have a table in = 3.1.5 representing a high level comparison of the three, but I don't = have a clear idea of what you consider complex, accurate, or timely. In = a future version, you may want to consider presenting the options as:=20 x.1 Description x.2 Strength x.3 Weakness And then in a following section, you can make a more detailed discussion = of the different approaches -- e.g., expanding on the table of 3.1.5. = In my opinion, by stating up front what the authors/editors perceive is = the strength and weakness of each, the reader can add further comment to = help refine the decision to a single approach. Afterwards, when one = approach is agreed upon, then perhaps you can either remove the = perceived strength/weakness or move it to an appendix. =20 2) for a lack of a better description, some of the sections seem to be = mis-numbered in terms of a hierarchy and collection of sections. It = seems odd that section 3.4 (Advanced Compatibility Mode) is separated = from the other three options of 1-bit, 3-bit, and code-point sections. = All of these options are meant to provide more reliability, and so any = comparison that you do in 3.1.5 would also seem to demand a comparison = of 3.4 Also, shouldn't the Requirements of 3.1.1 pertain to all of the options = of 3.1.2, 3.1.3, 3.1.4, and 3.4? And so, should the requirements = section be at a section level about the different options? I'll stress that this comment is more of a nit, but it would be helpful = to re-organize these sections for a better flow and cleaner presentation = of the points you want to make. 3) In the Discussion part of each of the options, you bring up the = impact of the potential loss of ACKs to congestion. I think you should = make it clear to the reader that the congestion and loss you speak of = concerning the ACKs from the receiver can be expected to be unrelated to = the congestion of the downstream data packets forwarded towards the = receiver. This will be obvious to the individuals familiar with ECN, = but not so much to the general reader. 4) for section 3.4, if you choose to cite what is observed in ns2, I = think its important to solicit and add information about other deployed = implementations. =20 5) one very small nit. I'd recommend changing the text "...(ECN) is an = IP/TCP mechanism..." to "..(ECN) is an mechanism..". A more generic = statement about ECN that doesn't identify a specific transport protocol = would reflect the work to add ECN support to DCCP and RTP/RTCP. cheers, -ken From philip.eardley@bt.com Thu Jul 7 05:34: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 15A2421F8754 for ; Thu, 7 Jul 2011 05:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQMMagx44wbk for ; Thu, 7 Jul 2011 05:34:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4021F86B9 for ; Thu, 7 Jul 2011 05:34:28 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 7 Jul 2011 13:34:26 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 7 Jul 2011 13:34:26 +0100 From: To: , Date: Thu, 7 Jul 2011 13:34:26 +0100 Thread-Topic: [conex] Non-goals and/or misconceptions for conex-concepts-uses Thread-Index: Acw8exBDnK3biF3vQ461HM9jzIKo8QAJbkFA Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D33C5D@EMV65-UKRD.domain1.systemhost.net> References: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> <4E156612.5030409@informatik.uni-tuebingen.de> In-Reply-To: <4E156612.5030409@informatik.uni-tuebingen.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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, 07 Jul 2011 12:34:30 -0000 Your suggestions look good.=20 Personally would put them later. A good, simple explanation of what conex i= s about should reduce the chances of a reader being misconceived. You could= always put an advert early in the doc Cong & utilisation - would make this a question in its own right. I'd expan= d it a bit. Explain how acting assuming it's one (& in fact it's the other)= leads to wrong 'cures'. Network traffic mgt does congestion control? - the bullet could be clearer.= TM can be on just as fast timescales as cong control. the "arbitrate overa= ll fairness" point is only one possibility for how TM can use conex info (&= the next bullet explains that case) I'm not sure the first question is quite right, but am not inspired with an= alternative at the moment -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of M= ichael Menth Sent: 07 July 2011 08:54 To: Briscoe,RJ,Bob,DES8 R Cc: ConEx IETF list Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-use= s Hi Bob, Am 07.07.2011 01:39, schrieb Bob Briscoe: > John, and all, > > To make this concrete, here's some items I could put in=20 > conex-concepts-uses. > > Some are non-goals. Some are misconceptions. Not in the sense that=20 > people are wrong about some objective fact. But in the sense that they=20 > are wrong about what ConEx is trying to say. Ie. Misconceptions about=20 > ConEx. > > All, =3D please suggest which ones are most important to keep, which=20 > ones can go, and which ones need clarifying. I'd put such a section rather at the end or in the appendix of the=20 document. Just brief feedback. > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/= \/\/\/\=20 > > 2.2. Common Misconceptions about ConEx > > Isn't good provisioning the way to solve congestion, not ConEx? > This is largely true. However a statement like this contains a > number of misconceptions about ConEx: > > * ConEx is not trying to 'solve' congestion, at least not > directly. ConEx is about making congestion visible as a useful > metric. > > * Once congestion-based traffic management is in place, the > operator can set a low congestion threshold to trigger and > target upgrades to bottlenecks (see Section 5.4). ... can use congestion information to trigger ... > > * Removing congestion completely is a non-goal. If an end-to-end > transport protocol cannot go fast enough to cause congestion > somewhere along the path, it is probably broken. So it is > misleading to selectively point to parts of a network (e.g. the > core) that are uncongested by design. Application performance > depends on the bottleneck, which a good transport protocol will > seek out--typically finding it in the access network (or all > too often in the receiver's buffer, but that's another story). > Low levels of congestion somewhere are therefore healthy. > > * Congestion and Utilisation are different. Protocols like TCP > aim to fill a link so the transfer finishes as quickly as > possible. If a link is 10% utilised on average, this can imply > it is 100% utilised 10% of the time. Or it might be 10% > utilised all the time. Averaging utilisation over a few > minutes hides what happened within the averaging time. In > contrast, measuring congestion-volume over the same few minutes > will distinguish between the two cases. The link to the major point must be better worked out. > > > > > Briscoe & Woundy Expires January 5, 2012 [Page 7] > > Internet-Draft ConEx Mechanism July 2011 > > > * It is not our place to judge. Many operators choose a mix of > traffic management and capacity upgrades, whether they run a > University network or a national ISP. Rather than beating our > chests about evil traffic management, the idea is to recognise > it is a legitimate choice, understand why poor practice is > widespread and enable best practice instead. At the same time > providing a good metric to support decisions on upgrading > bottlenecks too. Hm, difficult. Definitely needs rewording. > > Exposing Congestion to what? ConEx is about the sender exposing > congestion to the network, not the other way round. That would > not make sense in the context of the TCP/IP protocol suite, > because the end-systems already detect congestion by design. > > Is the idea for IP routers to use this congestion information? No > (but maybe). The sender puts ConEx information in the IP layer so > that specific functions can be deployed in the network to use it, > e.g. traffic management. These functions might be part of an edge > IP router, but might also be a separate box. Some ideas do exist > for forwarding on routers to optionally use ConEx (e.g. for > preferential discard), but that is not the current focus. > > Is the idea that network traffic management does congestion control? > No. The sender is still expected to do congestion control on fast > timescales. The reason the network needs congestion information > is not for congestion control, but to arbitrate overall fairness > at run-time. The meaning of the last sentence is not fully clear. > > But congestion control does fairness, doesn't it? Not really. > Congestion control determines the instantaneous shares of some > bottleneck links (absent network mechanisms like round-robin > scheduling). But it doesn't determine how much data an > application transfers, or how many flows it opens, or which > congestion control algorithm an application uses, or how many > applications the user runs, or how many users are active at once. > These factors all determine how great a share of a link is > available for any particular data transfer. Network operators use > traffic management to ensure some level of overall fairness given > all these factors. That's what the congestion information is > needed for. Should be dropped or reformulated. > > So you want the network to enforce compliance to the TCP algorithm? > Emphatically no. Some applications would not work if the network > forced everything to behave like TCP. This would also prevent > deployment of higher performance replacements to TCP. The idea of > ConEx is to only enforce overall bulk limits to congestion. Some > applications (e.g. short transfers) could be more aggressive than > TCP. Others (e.g. long transfers) could be less aggressive, > Interesting point, good to mention. Regards, Michael > > > Briscoe & Woundy Expires January 5, 2012 [Page 8] > > > > > > ________________________________________________________________ > 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 rs@netapp.com Thu Jul 7 05:36: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 7A7F621F8763 for ; Thu, 7 Jul 2011 05:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 s2ODyVTNuGuJ for ; Thu, 7 Jul 2011 05:36:51 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AC21F85D1 for ; Thu, 7 Jul 2011 05:36:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,493,1304319600"; d="scan'208";a="262675792" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 07 Jul 2011 05:36:49 -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 p67CanLY028584; Thu, 7 Jul 2011 05:36:49 -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); Thu, 7 Jul 2011 13:36:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 13:36:27 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F1E3513@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <008e01cc3c9e$cb32dfb0$61989f10$@cs.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] New draft(s) on TCP modifications for ConEx Thread-Index: AQGa0yk5C+jAK1WHfjhtu1emGlhaagJ5+/49A0Hqez4BmZ7r1AGaZDhelPwVLGCAAAdYwA== References: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> <5FDC413D5FA246468C200652D63E627A0F1E349D@LDCMVEXC1-PRD.hq.netapp.com> <008e01cc3c9e$cb32dfb0$61989f10$@cs.utwente.nl> From: "Scheffenegger, Richard" To: "Georgios Karagiannis" , "Bob Briscoe" X-OriginalArrivalTime: 07 Jul 2011 12:36:48.0944 (UTC) FILETIME=[8A4AFB00:01CC3CA2] Cc: conex@ietf.org Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 12:36:52 -0000 Hi Georgios, DCCP already features better-than-TCP ECN feedback (see section 11.4 of = RFC4340). Each Ack Vector option clearly indicated the exact stream of CE-marks in = the received packets. (And two distinct ACK vector options provide the = ECN Nonce feedback). Using that information, you can figure out the *exact* congestion volume = of a DCCP stream, without reverting to any post-hoc heuristic. But I believe Bob has already pointed out, that TCP is the only = transport which is in scope with conex WG? Richard Scheffenegger > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Donnerstag, 07. Juli 2011 14:10 > To: Scheffenegger, Richard; 'Bob Briscoe' > Cc: conex@ietf.org > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hi Richard, >=20 > You are right! The solution described in my draft only applies to > transport > protocols that are using TFRC . >=20 > So my proposal is: > Is it possible to combine our solutions, such that TCP based > applications, > but also DCCP based applications can use Conex? >=20 > Best regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: Scheffenegger, Richard [mailto:rs@netapp.com] > > Sent: donderdag 7 juli 2011 13:56 > > To: Georgios Karagiannis; Bob Briscoe > > Cc: conex@ietf.org > > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx > > > > Hi Georgios, > > > > > > If you choose to use formulas to estimate the transport rate, that > formula > > obviously has to apply to the transport protocol used. TFRC is > applicable > to > > DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. However, all > bets > > are off for *ANY* other transport (CBR VoIP over UDP / RTP). > > > > Furthermore, each of these transports has to have some form of > feedback > > mechanism from the receiver to the sender, so that the sender can > actually > > react to congestion. Thus, your scheme is implicitly completely > reliant on > > whatever feedback is available from the transport. > > > > RTP, for example, will have very extensive feedback (much more > extensive > > than what TCP, SCTP, DCCP can do) - see > http://tools.ietf.org/id/draft-ietf- > > avtcore-ecn-for-rtp-00.txt > > > > > > What Bob tried to point out is exactly that - your method applies a > specific, > > post-hoc method. This method implicitly relies on transport feedback > > already, but then simply appears to stuff all transports into a > TCP-friendly > > corset, which may not applicable at all. > > > > > > The goal of our drafts (accurate-ecn and conex-tcp-mods) is to > address the > > critical part, where the transport receiver gives the *appropriate* > (not > some > > estimated) congestion information back to the transport sender. With > TCP, > > we are unfortunately very constrained due to the very widespread use > (and > > also because TCP processing is poured into hardware these days), > which > > severly limits what can be done in a backwards-compatible way. > > > > Best regards, > > > > Richard Scheffenegger > > > > NetApp > > rs@netapp.com > > +43 1 3676811 3146 Office (2143 3146 - internal) > > +43 676 654 3146 Mobile > > www.netapp.com > > > > EURO PLAZA > > Geb=E4ude G, Stiege 7, 3.OG > > Am Euro Platz 2 > > A-1120 Wien > > > > > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Donnerstag, 07. Juli 2011 12:51 > > > To: 'Bob Briscoe' > > > Cc: conex@ietf.org > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > > > Hi Bob, > > > > > > > > > Please see in line! > > > > > > > > > > -----Original Message----- > > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > > Sent: donderdag 7 juli 2011 11:28 > > > > To: Georgios Karagiannis > > > > Cc: conex@ietf.org > > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > > > > > Georgios, > > > > > > > > >On 7/7/2011, "Georgios Karagiannis" > wrote: > > > > > >Regarding the beyond reasoning statement, it is better to not > > > discuss > > > > > >it via email, but face to face. Will you be in Quebec during > the > > > next > > > > > >IETF meeting? > > > > > > > > I meant that your response was not engaging in the reasoning put > to > > > you. > > > > > > > > You can go back and respond to the reasoning already given. But = I > > > don't > > > need > > > > to say any more. > > > > > > > > My main point was that the whole idea of your draft goes round = in > a > > > loop > > > > that achieves nothing. > > > > You avoided this critical point and jumped to a detail (a detail > > > within > > > that loop > > > > that already achieves nothing). > > > > > > Georgios: I am not sure if this loop applies to what is written = in > my > > > draft. > > > > > > > > > > > Now you are saying you meant something very different to what = you > > > > had written (you now say the draft was about DCCP, but the title > of > > > > your > > > draft > > > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP > takes > > > you > > > off- > > > > charter instead (see below). > > > > > > In the drafts I had not yet specified which transport protocol > should > > > be used, what I have specified was that the congestion exposure = can > be > > > calculated using the TCP throughput formula used in TFRC = (RFC5348). > > > And according to [RFC5348] "TFRC is a congestion control mechanism > > > designed for unicast flows operating in > > > an Internet environment and competing with TCP traffic = [FHPW00]. > > > Instead of specifying a complete protocol, this document simply > > > specifies a congestion control mechanism that could be used in = a > > > transport protocol such as DCCP (Datagram Congestion Control > > > Protocol) [RFC4340], in an application incorporating end-to-end > > > congestion control at the application level, or in the context > of > > > endpoint congestion management [BRS99].", from [RFC5348]. > > > > > > So I do not think that I was saying something in the previous = email > > > that is different than what is stated in my draft. > > > > > > > > > > > > > > At 07:08 07/07/2011, Georgios Karagiannis wrote: > > > > >Do you mean that is off-charter because is using for feedback > DCCP > > > > >& TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? > > > > > > > > Yes. > > > > > > > > ConEx is primarily at the IP layer, but some transports need > > > > optional > > > changes > > > > to their feedback. The charter says we will focus on TCP first. > > > > > > Georgios: In the charter the following is mentioned: > > > "Today, the network may signal > > > congestion by ECN markings or by dropping packets, and the = receiver > > > passes this information back to the sender in transport-layer > > > acknowledgements. The mechanism to be developed by the CONEX WG > > will > > > enable the sender to also relay the congestion information back > into > > > the network in-band at the IP layer, such that the total level of > > > congestion is visible to all IP devices along the path, from where > it > > > could, for example, be provided as input to traffic management." , > > > from [Conex charter] > > > > > > > > > Further down the charter mentions: > > > > > > "Primary work items are: > > > > > > * An Informational document containing an abstract description of > the > > > congestion exposure mechanism that is independent of specific > > > transport protocols and congestion information encoding techniques > > > needed for different IP protocol versions. > > > > > > * An Experimental specification of an IPv6 packet structure that > > > encapsulates CONEX information, defining a packet format and an > > > interpretation. > > > > > > > > > * An Experimental specification of a modification to TCP, for the > > > timely transport of congestion information from the destination to > the > > > sender.", from [Conex charter] > > > > > > > > > By reading the first paragraph from above, I can understand that > > > Conex WG will use transport-layer acknowledgement to pass the > > > congestion information (signalled by ECN markings or by dropping > > > packets to the receiver) from the receiver to the sender. > > > Thus any types of transport protocols can be used for this purpose > > > (e.g., TCP, DCCP). > > > > > > > > > By reading the third bullet from above, I can understand that the > > > CONEX WG will primarily focus on TCP. > > > > > > However, to my understanding this does not imply that other types > of > > > transport protocols, e.g. ., DCCP, are off-charter. This is in = my > > > opinion not explicitly mentioned in the charter. > > > > > > Could the WG chairs comment on this issues, see below: > > > > > > Conex needs transport protocols to carry congestion information > from a > > > receiver to a sender. > > > Are transport protocols such as DCCP out of the Conex charter > scope? > > > > > > > > > > > You are criticising a draft written to satisfy this charter > > > objective. You > > > are > > > > saying it is difficult to change the semantics of TCP header > fields > > > (which > > > we > > > > are already chartered to do). So you propose everyone should = have > to > > > use > > > > DCCP in order to use ConEx. That would require every application > in > > > the > > > > world that uses TCP to be changed to call DCCP instead, in order > to > > > use > > > > ConEx. And most middleboxes (NATs, firewalls) would have to be > > > changed > > > > too. > > > > > > Georgios: Sorry Bob, but this is your interpretation. > > > > > > Another interpretation could be: > > > It is good to provide the means such that Conex is used in > combination > > > with applications that are using not only TCP as a transport > protocol, > > > but also the ones that are using DCCP as transport protocol. > > > Furthermore, start with a solution to calculate congestion, in > this > > > case the TFRC [RF5348], that is simple and does not imply many > > > standardization changes on the transport protocols using this > > > solution. > > > Moreover, note that I am in favour that a TCP based transport > solution > > > should be specified in parallel. > > > > > > Best regards, > > > Georgios > > > > > > > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Thu Jul 7 05: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 65E1521F8802 for ; Thu, 7 Jul 2011 05:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 f4EnDVdnrrQ4 for ; Thu, 7 Jul 2011 05:49:35 -0700 (PDT) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by ietfa.amsl.com (Postfix) with ESMTP id B87D421F87F8 for ; Thu, 7 Jul 2011 05:49:34 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p67CnQFp021432; Thu, 7 Jul 2011 14:49:26 +0200 From: "Georgios Karagiannis" To: "'Scheffenegger, Richard'" , "'Bob Briscoe'" References: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> <5FDC413D5FA246468C200652D63E627A0F1E349D@LDCMVEXC1-PRD.hq.netapp.com> <008e01cc3c9e$cb32dfb0$61989f10$@cs.utwente.nl> <5FDC413D5FA246468C200652D63E627A0F1E3513@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F1E3513@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 7 Jul 2011 14:49:26 +0200 Message-ID: <009501cc3ca4$4f5d7610$ee186230$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGa0yk5C+jAK1WHfjhtu1emGlhaagJ5+/49A0Hqez4BmZ7r1AGaZDheAk2+3A8BttyY95Tb+1Lw Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: conex@ietf.org Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 12:49:36 -0000 Hi Richard, Thanks for the information! Best regards, Georgios > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com] > Sent: donderdag 7 juli 2011 14:36 > To: Georgios Karagiannis; Bob Briscoe > Cc: conex@ietf.org > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx >=20 > Hi Georgios, >=20 > DCCP already features better-than-TCP ECN feedback (see section 11.4 = of > RFC4340). >=20 > Each Ack Vector option clearly indicated the exact stream of CE-marks = in the > received packets. (And two distinct ACK vector options provide the ECN > Nonce feedback). >=20 > Using that information, you can figure out the *exact* congestion = volume of > a DCCP stream, without reverting to any post-hoc heuristic. >=20 >=20 > But I believe Bob has already pointed out, that TCP is the only = transport > which is in scope with conex WG? >=20 > Richard Scheffenegger >=20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Donnerstag, 07. Juli 2011 14:10 > > To: Scheffenegger, Richard; 'Bob Briscoe' > > Cc: conex@ietf.org > > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx > > > > Hi Richard, > > > > You are right! The solution described in my draft only applies to > > transport protocols that are using TFRC . > > > > So my proposal is: > > Is it possible to combine our solutions, such that TCP based > > applications, but also DCCP based applications can use Conex? > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > From: Scheffenegger, Richard [mailto:rs@netapp.com] > > > Sent: donderdag 7 juli 2011 13:56 > > > To: Georgios Karagiannis; Bob Briscoe > > > Cc: conex@ietf.org > > > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx > > > > > > Hi Georgios, > > > > > > > > > If you choose to use formulas to estimate the transport rate, that > > formula > > > obviously has to apply to the transport protocol used. TFRC is > > applicable > > to > > > DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. However, all > > bets > > > are off for *ANY* other transport (CBR VoIP over UDP / RTP). > > > > > > Furthermore, each of these transports has to have some form of > > feedback > > > mechanism from the receiver to the sender, so that the sender can > > actually > > > react to congestion. Thus, your scheme is implicitly completely > > reliant on > > > whatever feedback is available from the transport. > > > > > > RTP, for example, will have very extensive feedback (much more > > extensive > > > than what TCP, SCTP, DCCP can do) - see > > http://tools.ietf.org/id/draft-ietf- > > > avtcore-ecn-for-rtp-00.txt > > > > > > > > > What Bob tried to point out is exactly that - your method applies = a > > specific, > > > post-hoc method. This method implicitly relies on transport = feedback > > > already, but then simply appears to stuff all transports into a > > TCP-friendly > > > corset, which may not applicable at all. > > > > > > > > > The goal of our drafts (accurate-ecn and conex-tcp-mods) is to > > address the > > > critical part, where the transport receiver gives the = *appropriate* > > (not > > some > > > estimated) congestion information back to the transport sender. = With > > TCP, > > > we are unfortunately very constrained due to the very widespread = use > > (and > > > also because TCP processing is poured into hardware these days), > > which > > > severly limits what can be done in a backwards-compatible way. > > > > > > Best regards, > > > > > > Richard Scheffenegger > > > > > > NetApp > > > rs@netapp.com > > > +43 1 3676811 3146 Office (2143 3146 - internal) > > > +43 676 654 3146 Mobile > > > www.netapp.com > > > > > > EURO PLAZA > > > Geb=E4ude G, Stiege 7, 3.OG > > > Am Euro Platz 2 > > > A-1120 Wien > > > > > > > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: Donnerstag, 07. Juli 2011 12:51 > > > > To: 'Bob Briscoe' > > > > Cc: conex@ietf.org > > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > > > > > Hi Bob, > > > > > > > > > > > > Please see in line! > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > > > Sent: donderdag 7 juli 2011 11:28 > > > > > To: Georgios Karagiannis > > > > > Cc: conex@ietf.org > > > > > Subject: Re: [conex] New draft(s) on TCP modifications for = ConEx > > > > > > > > > > Georgios, > > > > > > > > > > >On 7/7/2011, "Georgios Karagiannis" > > wrote: > > > > > > >Regarding the beyond reasoning statement, it is better to = not > > > > discuss > > > > > > >it via email, but face to face. Will you be in Quebec = during > > the > > > > next > > > > > > >IETF meeting? > > > > > > > > > > I meant that your response was not engaging in the reasoning = put > > to > > > > you. > > > > > > > > > > You can go back and respond to the reasoning already given. = But > > > > > I > > > > don't > > > > need > > > > > to say any more. > > > > > > > > > > My main point was that the whole idea of your draft goes round > > > > > in > > a > > > > loop > > > > > that achieves nothing. > > > > > You avoided this critical point and jumped to a detail (a = detail > > > > within > > > > that loop > > > > > that already achieves nothing). > > > > > > > > Georgios: I am not sure if this loop applies to what is written > > > > in > > my > > > > draft. > > > > > > > > > > > > > > Now you are saying you meant something very different to what > > > > > you had written (you now say the draft was about DCCP, but the > > > > > title > > of > > > > > your > > > > draft > > > > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP > > takes > > > > you > > > > off- > > > > > charter instead (see below). > > > > > > > > In the drafts I had not yet specified which transport protocol > > should > > > > be used, what I have specified was that the congestion exposure > > > > can > > be > > > > calculated using the TCP throughput formula used in TFRC = (RFC5348). > > > > And according to [RFC5348] "TFRC is a congestion control = mechanism > > > > designed for unicast flows operating in > > > > an Internet environment and competing with TCP traffic = [FHPW00]. > > > > Instead of specifying a complete protocol, this document = simply > > > > specifies a congestion control mechanism that could be used = in a > > > > transport protocol such as DCCP (Datagram Congestion Control > > > > Protocol) [RFC4340], in an application incorporating = end-to-end > > > > congestion control at the application level, or in the = context > > of > > > > endpoint congestion management [BRS99].", from [RFC5348]. > > > > > > > > So I do not think that I was saying something in the previous > > > > email that is different than what is stated in my draft. > > > > > > > > > > > > > > > > > > At 07:08 07/07/2011, Georgios Karagiannis wrote: > > > > > >Do you mean that is off-charter because is using for feedback > > DCCP > > > > > >& TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? > > > > > > > > > > Yes. > > > > > > > > > > ConEx is primarily at the IP layer, but some transports need > > > > > optional > > > > changes > > > > > to their feedback. The charter says we will focus on TCP = first. > > > > > > > > Georgios: In the charter the following is mentioned: > > > > "Today, the network may signal > > > > congestion by ECN markings or by dropping packets, and the > > > > receiver passes this information back to the sender in > > > > transport-layer acknowledgements. The mechanism to be developed > by > > > > the CONEX WG > > > will > > > > enable the sender to also relay the congestion information back > > into > > > > the network in-band at the IP layer, such that the total level = of > > > > congestion is visible to all IP devices along the path, from = where > > it > > > > could, for example, be provided as input to traffic management." = , > > > > from [Conex charter] > > > > > > > > > > > > Further down the charter mentions: > > > > > > > > "Primary work items are: > > > > > > > > * An Informational document containing an abstract description = of > > the > > > > congestion exposure mechanism that is independent of specific > > > > transport protocols and congestion information encoding = techniques > > > > needed for different IP protocol versions. > > > > > > > > * An Experimental specification of an IPv6 packet structure that > > > > encapsulates CONEX information, defining a packet format and an > > > > interpretation. > > > > > > > > > > > > * An Experimental specification of a modification to TCP, for = the > > > > timely transport of congestion information from the destination = to > > the > > > > sender.", from [Conex charter] > > > > > > > > > > > > By reading the first paragraph from above, I can understand = that > > > > Conex WG will use transport-layer acknowledgement to pass the > > > > congestion information (signalled by ECN markings or by dropping > > > > packets to the receiver) from the receiver to the sender. > > > > Thus any types of transport protocols can be used for this = purpose > > > > (e.g., TCP, DCCP). > > > > > > > > > > > > By reading the third bullet from above, I can understand that = the > > > > CONEX WG will primarily focus on TCP. > > > > > > > > However, to my understanding this does not imply that other = types > > of > > > > transport protocols, e.g. ., DCCP, are off-charter. This is in > > > > my opinion not explicitly mentioned in the charter. > > > > > > > > Could the WG chairs comment on this issues, see below: > > > > > > > > Conex needs transport protocols to carry congestion information > > from a > > > > receiver to a sender. > > > > Are transport protocols such as DCCP out of the Conex charter > > scope? > > > > > > > > > > > > > > You are criticising a draft written to satisfy this charter > > > > objective. You > > > > are > > > > > saying it is difficult to change the semantics of TCP header > > fields > > > > (which > > > > we > > > > > are already chartered to do). So you propose everyone should > > > > > have > > to > > > > use > > > > > DCCP in order to use ConEx. That would require every = application > > in > > > > the > > > > > world that uses TCP to be changed to call DCCP instead, in = order > > to > > > > use > > > > > ConEx. And most middleboxes (NATs, firewalls) would have to be > > > > changed > > > > > too. > > > > > > > > Georgios: Sorry Bob, but this is your interpretation. > > > > > > > > Another interpretation could be: > > > > It is good to provide the means such that Conex is used in > > combination > > > > with applications that are using not only TCP as a transport > > protocol, > > > > but also the ones that are using DCCP as transport protocol. > > > > Furthermore, start with a solution to calculate congestion, in > > this > > > > case the TFRC [RF5348], that is simple and does not imply many > > > > standardization changes on the transport protocols using this > > > > solution. > > > > Moreover, note that I am in favour that a TCP based transport > > solution > > > > should be specified in parallel. > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > _______________________________________________ > > > > conex mailing list > > > > conex@ietf.org > > > > https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Thu Jul 7 06:02: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 95C0D21F86B0 for ; Thu, 7 Jul 2011 06:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.34 X-Spam-Level: X-Spam-Status: No, score=-1.34 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 iUQP9RKXlA2m for ; Thu, 7 Jul 2011 06:02:24 -0700 (PDT) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB67C21F869C for ; Thu, 7 Jul 2011 06:02:23 -0700 (PDT) Received: from UTWKS03025 (utwks03025.ad.utwente.nl [130.89.12.129]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p67D2I3i030470; Thu, 7 Jul 2011 15:02:18 +0200 From: "Georgios Karagiannis" To: "'marcelo bagnulo braun'" References: <4E15A171.7070205@it.uc3m.es> In-Reply-To: <4E15A171.7070205@it.uc3m.es> Date: Thu, 7 Jul 2011 15:02:18 +0200 Message-ID: <009701cc3ca6$1a335070$4e99f150$@cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjpZMKGVLtUBVqrBLpAIj9Z4+4YAIcYrX6lCEbKiA= Content-Language: nl X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: karagian@cs.utwente.nl Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 13:02:24 -0000 Hi Marcelo, Before answering your question, can you please inform me whether = solutions that use DCCP as transport protocol to carry congestion information feedbacks from the receiver to the sender is off-charter? These drafts are actually are using TFRC [RFC5348] to calculate the TCP throughput at the sender (implying that a transport protocol like DCCP should be used)! Best regards, Georgios > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: donderdag 7 juli 2011 14:07 > To: Georgios Karagiannis > Cc: 'ConEx IETF list' > Subject: Re: [conex] Draft agenda >=20 > Hi Georgios, >=20 > Could you clarify to me if these drafts fit in our current charter and how? >=20 > (just to be clear, we can have presentations that don't fit in our charter, but it > is importnat to understand what the purpose of the docuemnt is) >=20 > Regards, marcelo >=20 >=20 > El 06/07/11 21:52, Georgios Karagiannis escribi=F3: > > Hi Marcelo, > > > > Is it possible to get a 10 minutes agenda slot for each of the two > > below > > dafts: > > > > = http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion-cal > > culation/ > > > > = http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01. > > txt > > > > Best regards, > > Georgios > > > > > > > > > > On 7/6/2011, "marcelo bagnulo braun" wrote: > > > >> The draft agenda is posted. > >> http://www.ietf.org/proceedings/81/agenda/conex.txt > >> Let me know if there are changes. > >> Regards, marcelo > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex From philip.eardley@bt.com Thu Jul 7 06:13: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 4687C21F8736 for ; Thu, 7 Jul 2011 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msN9yLotSSvd for ; Thu, 7 Jul 2011 06:13:07 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id D05F121F873A for ; Thu, 7 Jul 2011 06:13:06 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 7 Jul 2011 14:13:04 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 7 Jul 2011 14:13:04 +0100 From: To: , Date: Thu, 7 Jul 2011 14:13:03 +0100 Thread-Topic: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC Thread-Index: Acw7y3j92Yr+pSkNRHyTqtCwItueXgA1s0LQ Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> In-Reply-To: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 07 Jul 2011 13:13:08 -0000 Bob, On the Use cases, I'd say something like:- Conex enables IP nodes to see information about the whole path congestion, = so that it is visible as a useful metric; some of the use cases thereby ena= bled are: (1) Inform the operator's traffic management (2) Side impact - incentivise scavenger transports (3) Side impact - enable enduser-controlled QoS (4) Inform the operator's provisioning process (5) Inform the interconnect agreement between two operators - i deliberately included the first sentence [before the list]. I think it'= s important to be clear about what the conex capability is, as these are ca= ses that use that capability. (this may also help clarify what other stuff = is needed by a particular use case) - i think it's much clearer to say what conex directly enables (1, 4, 5) an= d what it, as a side effect, encourages to happen (2, 3). I think it's help= ful to have 'Side impact' in the section title.=20 - i think my 3 is the same as your 'intra-class QoS', but is of slightly wi= der scope & also makes it clearer that it's interesting for the end user. A= nyway, what i mean is the flip side of (2) - enable the-opposite-of-scaveng= er transports. - 'accounting for congestion' is already covered within (1). The text in S5= .3 of the I-D (current version, -01) is slightly philosophical about what t= hings would be like if everyone used conex. I dont think it's needed. If yo= u really want it, how about a section towards the end of the doc that cover= s longer-terms vision etc. Anyway, it doesnt read like a use case to me.=20 - personally i think that (4) is important enough it shouldn't be hidden as= a sub-case - (5) is a bit trickier, as it requres 2 operators to be using conex. Perso= nally i'd prefer to show it as a use case, rather than hide it in 'other us= e cases' - i think it's important to get the wording of the section titles right. Eg= "Provisioning capacity" is poor (something like " Inform the operator's pr= ovisioning process" is better).=20 - re " Preventing congestion collapse" - this fails the previous comment. A= nyway, it sounds more like a possible benefit than a use case. Dont think i= t's needed.=20 - re " Mitigating flooding attacks". I suspect not mentioning is the pragma= tic approach. Other comments: 'concepts' rather than 'definitions' is great. The current page count in th= e ToC suggests you only have text under 'definitions'. Suggest you work as = much as possible, ie describe the concepts! 'Deployment arrangements' - much better 'self congestion' - agree. Thanks, phil=20 -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of B= ob Briscoe Sent: 06 July 2011 11:57 To: ConEx IETF list Subject: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC ConEx folks, The proposed table of contents for draft-02 is pasted at the end. Please react if you object. There will be controversy, but please try=20 to recognise that we ought to be converging now. Here's the rationale for the changes. 2. Definitions -> Concepts The "Definitions" section in draft-01 actually introduced the main=20 concepts, which is goal #1 of this doc. So Concepts is a better=20 section heading. Then we've added the much-discussed Misconceptions sub-section=20 clarifying it's not misconceptions about networking, just about ConEx. 5. ConEx Use Cases Removed one use-case (Accounting for Congestion Volume) but really=20 just moved it to "Other Use-Cases" so it can be much shorter. Under "Other Use-Cases", we propose very brief bullets on each of: * Preventing congestion collapse * Accounting for congestion * Interconnection traffic contracts * Provisioning capacity The idea is to resolve all the to-and-fro about which use-cases=20 should be in or out, by having a "half-in" category. And possibly (controversial!) we could then even add... * Mitigating flooding attacks =09 Note also the change of heading: 5.3. ConEx for Intra-Class Quality of Service (QoS) We'll change the story to emphasise that ConEx doesn't replace=20 Diffserv, but it could handle allocation of resources within a class=20 (ie bandwidth allocation as opposed to queue scheduling). 6. Deployment Arrangements. Replaces previous S.5.5. Partial vs. Full Deployment It's tough to talk about deployment in a mechanism-neutral way (given=20 deployment is about deploying mechanisms!). Nonetheless, the idea is=20 to give a plausible story for how the previously mentioned use-cases=20 would get incrementally deployed. So it fits in this doc, but it will=20 be tough. We have summarised stuff about components and incremental=20 deployment in abstract-mech first (I intend to post proposed new text=20 for this section to the list shortly). 7.2. Self Congestion Rather than diving straight into this detailed area early in the=20 Introduction, we've moved it to where it belongs: under 7. Potential Issues= . /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/= \/\/\/\/\ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Common Misconceptions about ConEx . . . . . . . . . . . . 7 3. Traffic Management . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 8 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 9 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 10 5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. ConEx as a basis for traffic management . . . . . . . . . 11 5.2. ConEx to incentivise scavenger transports . . . . . . . . 11 5.3. ConEx for Intra-Class Quality of Service (QoS) . . . . . . 12 5.4. Other Use-Cases . . . . . . . . . . . . . . . . . . . . . 13 6. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 13 6.1. Deployment Concepts . . . . . . . . . . . . . . . . . . . 13 6.2. Single Receiving Network Scenario . . . . . . . . . . . . 14 6.3. Other Initial Deployment Scenarios . . . . . . . . . . . . 14 7. Potential Issues . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Congestion as a Commercial Secret . . . . . . . . . . . . 14 7.2. Self Congestion . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8.1. Information Security . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 18 12. Informative References . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes from previous drafts (to be removed by the RFC Editor) . . . . . . . . . . . . . . . . . . . 19 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/= \/\/\/\/\ Cheers Bob (& discussed with Rich as co-editor, but still some uncertainties=20 - hence asking the list for views) Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From menth@informatik.uni-tuebingen.de Thu Jul 7 06:44: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 327A51F0C3C for ; Thu, 7 Jul 2011 06:44:13 -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 deyaNZNmBQqB for ; Thu, 7 Jul 2011 06:44:12 -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 B6EF31F0C36 for ; Thu, 7 Jul 2011 06:44:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8E3AB527A; Thu, 7 Jul 2011 15:43:56 +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 l+bdP15KIYou; Thu, 7 Jul 2011 15:43:51 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D37DE5250; Thu, 7 Jul 2011 15:43:50 +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 CE36120255D7; Thu, 7 Jul 2011 15:43:50 +0200 (CEST) Message-ID: <4E15B816.2070603@informatik.uni-tuebingen.de> Date: Thu, 07 Jul 2011 15:43:50 +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: philip.eardley@bt.com References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: conex@ietf.org Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 07 Jul 2011 13:44:13 -0000 +1 Am 07.07.2011 15:13, schrieb philip.eardley@bt.com: > Bob, > > On the Use cases, I'd say something like:- > > Conex enables IP nodes to see information about the whole path congestion, so that it is visible as a useful metric; some of the use cases thereby enabled are: > (1) Inform the operator's traffic management > (2) Side impact - incentivise scavenger transports > (3) Side impact - enable enduser-controlled QoS > (4) Inform the operator's provisioning process > (5) Inform the interconnect agreement between two operators > > - i deliberately included the first sentence [before the list]. I think it's important to be clear about what the conex capability is, as these are cases that use that capability. (this may also help clarify what other stuff is needed by a particular use case) > - i think it's much clearer to say what conex directly enables (1, 4, 5) and what it, as a side effect, encourages to happen (2, 3). I think it's helpful to have 'Side impact' in the section title. > - i think my 3 is the same as your 'intra-class QoS', but is of slightly wider scope& also makes it clearer that it's interesting for the end user. Anyway, what i mean is the flip side of (2) - enable the-opposite-of-scavenger transports. > - 'accounting for congestion' is already covered within (1). The text in S5.3 of the I-D (current version, -01) is slightly philosophical about what things would be like if everyone used conex. I dont think it's needed. If you really want it, how about a section towards the end of the doc that covers longer-terms vision etc. Anyway, it doesnt read like a use case to me. > - personally i think that (4) is important enough it shouldn't be hidden as a sub-case > - (5) is a bit trickier, as it requres 2 operators to be using conex. Personally i'd prefer to show it as a use case, rather than hide it in 'other use cases' > - i think it's important to get the wording of the section titles right. Eg "Provisioning capacity" is poor (something like " Inform the operator's provisioning process" is better). > - re " Preventing congestion collapse" - this fails the previous comment. Anyway, it sounds more like a possible benefit than a use case. Dont think it's needed. > - re " Mitigating flooding attacks". I suspect not mentioning is the pragmatic approach. > > > Other comments: > 'concepts' rather than 'definitions' is great. The current page count in the ToC suggests you only have text under 'definitions'. Suggest you work as much as possible, ie describe the concepts! > > 'Deployment arrangements' - much better > 'self congestion' - agree. > > Thanks, > phil > > > > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Bob Briscoe > Sent: 06 July 2011 11:57 > To: ConEx IETF list > Subject: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC > > ConEx folks, > > The proposed table of contents for draft-02 is pasted at the end. > Please react if you object. There will be controversy, but please try > to recognise that we ought to be converging now. > > Here's the rationale for the changes. > > 2. Definitions -> Concepts > > The "Definitions" section in draft-01 actually introduced the main > concepts, which is goal #1 of this doc. So Concepts is a better > section heading. > Then we've added the much-discussed Misconceptions sub-section > clarifying it's not misconceptions about networking, just about ConEx. > > 5. ConEx Use Cases > Removed one use-case (Accounting for Congestion Volume) but really > just moved it to "Other Use-Cases" so it can be much shorter. > > Under "Other Use-Cases", we propose very brief bullets on each of: > * Preventing congestion collapse > * Accounting for congestion > * Interconnection traffic contracts > * Provisioning capacity > > The idea is to resolve all the to-and-fro about which use-cases > should be in or out, by having a "half-in" category. > > And possibly (controversial!) we could then even add... > * Mitigating flooding attacks > > Note also the change of heading: > 5.3. ConEx for Intra-Class Quality of Service (QoS) > We'll change the story to emphasise that ConEx doesn't replace > Diffserv, but it could handle allocation of resources within a class > (ie bandwidth allocation as opposed to queue scheduling). > > 6. Deployment Arrangements. > > Replaces previous S.5.5. Partial vs. Full Deployment > > It's tough to talk about deployment in a mechanism-neutral way (given > deployment is about deploying mechanisms!). Nonetheless, the idea is > to give a plausible story for how the previously mentioned use-cases > would get incrementally deployed. So it fits in this doc, but it will > be tough. We have summarised stuff about components and incremental > deployment in abstract-mech first (I intend to post proposed new text > for this section to the list shortly). > > 7.2. Self Congestion > > Rather than diving straight into this detailed area early in the > Introduction, we've moved it to where it belongs: under 7. Potential Issues. > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.2. Common Misconceptions about ConEx . . . . . . . . . . . . 7 > 3. Traffic Management . . . . . . . . . . . . . . . . . . . . . . 7 > 3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 8 > 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 9 > 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 10 > 5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11 > 5.1. ConEx as a basis for traffic management . . . . . . . . . 11 > 5.2. ConEx to incentivise scavenger transports . . . . . . . . 11 > 5.3. ConEx for Intra-Class Quality of Service (QoS) . . . . . . 12 > 5.4. Other Use-Cases . . . . . . . . . . . . . . . . . . . . . 13 > 6. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 13 > 6.1. Deployment Concepts . . . . . . . . . . . . . . . . . . . 13 > 6.2. Single Receiving Network Scenario . . . . . . . . . . . . 14 > 6.3. Other Initial Deployment Scenarios . . . . . . . . . . . . 14 > 7. Potential Issues . . . . . . . . . . . . . . . . . . . . . . . 14 > 7.1. Congestion as a Commercial Secret . . . . . . . . . . . . 14 > 7.2. Self Congestion . . . . . . . . . . . . . . . . . . . . . 15 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 > 8.1. Information Security . . . . . . . . . . . . . . . . . . . 16 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 > 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 > 11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 18 > 12. Informative References . . . . . . . . . . . . . . . . . . . . 18 > Appendix A. Changes from previous drafts (to be removed by > the RFC Editor) . . . . . . . . . . . . . . . . . . . 19 > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > Cheers > > Bob (& discussed with Rich as co-editor, but still some uncertainties > - hence asking the list for views) > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT Innovate& Design > > _______________________________________________ > 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 -- 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 Thu Jul 7 06:46: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 C327D21F85AA for ; Thu, 7 Jul 2011 06:46:08 -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 114NOCw3458Z for ; Thu, 7 Jul 2011 06:46:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7E21F867A for ; Thu, 7 Jul 2011 06:46:07 -0700 (PDT) Received: from TobysHP (host86-132-207-197.range86-132.btcentralplus.com [86.132.207.197]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lzai2-1RaRps1iok-014j8F; Thu, 07 Jul 2011 15:46:06 +0200 From: "Toby Moncaster" To: "'Georgios Karagiannis'" , "'marcelo bagnulo braun'" References: <4E15A171.7070205@it.uc3m.es> <009701cc3ca6$1a335070$4e99f150$@cs.utwente.nl> In-Reply-To: <009701cc3ca6$1a335070$4e99f150$@cs.utwente.nl> Date: Thu, 7 Jul 2011 14:46:03 +0100 Message-ID: <00d101cc3cac$3742ade0$a5c809a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQIjpZMKGVLtUBVqrBLpAIj9Z4+4YAIcYrX6lCEbKiCAAAzgwA== Content-Language: en-gb X-Provags-ID: V02:K0:W4C1ZZwU6k7E4VlL15YwZpNXe9YD7hl+mdK1lQs4Mwi P8FYtuH4ticzr8/lHHBPsNc34WhQmCivfXE9SFXoJZA/e5XVDh xYiSRIwri1wqLwUxDFlDKeaq649n3ouuP6IDh3/DABn5Mfk/ZX zTVMZsvM9HzURfEL3etD7AZ2rt7pglau48sovQQTAVxC57GOQ5 hNVb0/kSFjmgJK7hWn3wPNPgOcEQemkg1h+/im35l0= Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 13:46:08 -0000 Speaking personally I would worry that these drafts are out of scope for = the IETF itself. These seem to be ideas in their infancy and thus seem far = more suitable for work in the IRTF. Failing that it just might fall in scope = for TSVArea? It took us a very long time to convince the IESG that ConEx itself was a mature enough concept to be chartered. Right now the WG is (barely) on = track to complete the items on its core charter. Now is not the time to start adding new work, especially not when that work seems so far from = maturity. I do have to admit that I haven't been following this debate all that = well, but what I have followed suggests to me this could just end up being a time-sink with no end benefit to the working group and the wider IETF. Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Georgios Karagiannis > Sent: 07 July 2011 14:02 > To: 'marcelo bagnulo braun' > Cc: 'ConEx IETF list' > Subject: Re: [conex] Draft agenda >=20 > Hi Marcelo, >=20 > Before answering your question, can you please inform me whether > solutions > that use DCCP as transport protocol to carry congestion information > feedbacks from the receiver to the sender is off-charter? >=20 > These drafts are actually are using TFRC [RFC5348] to calculate the = TCP > throughput at the sender (implying that a transport protocol like DCCP > should be used)! >=20 > Best regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > Sent: donderdag 7 juli 2011 14:07 > > To: Georgios Karagiannis > > Cc: 'ConEx IETF list' > > Subject: Re: [conex] Draft agenda > > > > Hi Georgios, > > > > Could you clarify to me if these drafts fit in our current charter > and > how? > > > > (just to be clear, we can have presentations that don't fit in our > charter, but it > > is importnat to understand what the purpose of the docuemnt is) > > > > Regards, marcelo > > > > > > El 06/07/11 21:52, Georgios Karagiannis escribi=F3: > > > Hi Marcelo, > > > > > > Is it possible to get a 10 minutes agenda slot for each of the two > > > below > > > dafts: > > > > > > = http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion- > cal > > > culation/ > > > > > > = http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure- > 01. > > > txt > > > > > > Best regards, > > > Georgios > > > > > > > > > > > > > > > On 7/6/2011, "marcelo bagnulo braun" wrote: > > > > > >> The draft agenda is posted. > > >> http://www.ietf.org/proceedings/81/agenda/conex.txt > > >> Let me know if there are changes. > > >> Regards, marcelo > > >> > > >> _______________________________________________ > > >> conex mailing list > > >> conex@ietf.org > > >> https://www.ietf.org/mailman/listinfo/conex >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Thu Jul 7 07:03: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 938AE1F0C3F for ; Thu, 7 Jul 2011 07:03:21 -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 jTholA3+SfB7 for ; Thu, 7 Jul 2011 07:03:21 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id AFB5F1F0C3A for ; Thu, 7 Jul 2011 07:03:19 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id CF1567F44C7; Thu, 7 Jul 2011 16:03:17 +0200 (CEST) Message-ID: <4E15BCA4.7080503@it.uc3m.es> Date: Thu, 07 Jul 2011 16:03:16 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Georgios Karagiannis References: <4E15A171.7070205@it.uc3m.es> <009701cc3ca6$1a335070$4e99f150$@cs.utwente.nl> In-Reply-To: <009701cc3ca6$1a335070$4e99f150$@cs.utwente.nl> 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.8.0.1017-18244.007 Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 14:03:21 -0000 Hi, the charter reads as follows: * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. So, i would say it is off charter. Morevoer, i believe it makes sense to focus our work on TCP right now, since it seems to be more widely used than DCCP. Makes sense? Regards, marcelo El 07/07/11 15:02, Georgios Karagiannis escribió: > Hi Marcelo, > > Before answering your question, can you please inform me whether solutions > that use DCCP as transport protocol to carry congestion information > feedbacks from the receiver to the sender is off-charter? > > These drafts are actually are using TFRC [RFC5348] to calculate the TCP > throughput at the sender (implying that a transport protocol like DCCP > should be used)! > > Best regards, > Georgios > > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: donderdag 7 juli 2011 14:07 >> To: Georgios Karagiannis >> Cc: 'ConEx IETF list' >> Subject: Re: [conex] Draft agenda >> >> Hi Georgios, >> >> Could you clarify to me if these drafts fit in our current charter and > how? >> (just to be clear, we can have presentations that don't fit in our > charter, but it >> is importnat to understand what the purpose of the docuemnt is) >> >> Regards, marcelo >> >> >> El 06/07/11 21:52, Georgios Karagiannis escribió: >>> Hi Marcelo, >>> >>> Is it possible to get a 10 minutes agenda slot for each of the two >>> below >>> dafts: >>> >>> http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion-cal >>> culation/ >>> >>> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01. >>> txt >>> >>> Best regards, >>> Georgios >>> >>> >>> >>> >>> On 7/6/2011, "marcelo bagnulo braun" wrote: >>> >>>> The draft agenda is posted. >>>> http://www.ietf.org/proceedings/81/agenda/conex.txt >>>> Let me know if there are changes. >>>> Regards, marcelo >>>> >>>> _______________________________________________ >>>> conex mailing list >>>> conex@ietf.org >>>> https://www.ietf.org/mailman/listinfo/conex > From marcelo@it.uc3m.es Thu Jul 7 07:08:37 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 AED8111E8074 for ; Thu, 7 Jul 2011 07:08:37 -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 NnmfU+l422P5 for ; Thu, 7 Jul 2011 07:08:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B749D11E8073 for ; Thu, 7 Jul 2011 07:08:36 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id A5547C2835C; Thu, 7 Jul 2011 16:08:31 +0200 (CEST) Message-ID: <4E15BDDF.8030108@it.uc3m.es> Date: Thu, 07 Jul 2011 16:08:31 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Toby Moncaster References: <4E15A171.7070205@it.uc3m.es> <009701cc3ca6$1a335070$4e99f150$@cs.utwente.nl> <00d101cc3cac$3742ade0$a5c809a0$@com> In-Reply-To: <00d101cc3cac$3742ade0$a5c809a0$@com> 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.8.0.1017-18244.007 Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 14:08:37 -0000 I personally don't mind having discussions related to the topic of the WG in the meetings as long as: - We only do them if we have spare time once we are done with our charter times (i.e. not cut disucssion for wg items in order to have these others presented/present if time permits) - there is a very clear expectation of what the near future of this work is i.e. are potential candidates for recharter _after_ we are done with our current work items - there is interest. El 07/07/11 15:46, Toby Moncaster escribió: > Speaking personally I would worry that these drafts are out of scope for the > IETF itself. These seem to be ideas in their infancy and thus seem far more > suitable for work in the IRTF. Failing that it just might fall in scope for > TSVArea? > > It took us a very long time to convince the IESG that ConEx itself was a > mature enough concept to be chartered. Right now the WG is (barely) on track > to complete the items on its core charter. Now is not the time to start > adding new work, especially not when that work seems so far from maturity. > > I do have to admit that I haven't been following this debate all that well, > but what I have followed suggests to me this could just end up being a > time-sink with no end benefit to the working group and the wider IETF. > > Toby > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of Georgios Karagiannis >> Sent: 07 July 2011 14:02 >> To: 'marcelo bagnulo braun' >> Cc: 'ConEx IETF list' >> Subject: Re: [conex] Draft agenda >> >> Hi Marcelo, >> >> Before answering your question, can you please inform me whether >> solutions >> that use DCCP as transport protocol to carry congestion information >> feedbacks from the receiver to the sender is off-charter? >> >> These drafts are actually are using TFRC [RFC5348] to calculate the TCP >> throughput at the sender (implying that a transport protocol like DCCP >> should be used)! >> >> Best regards, >> Georgios >> >> >> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: donderdag 7 juli 2011 14:07 >>> To: Georgios Karagiannis >>> Cc: 'ConEx IETF list' >>> Subject: Re: [conex] Draft agenda >>> >>> Hi Georgios, >>> >>> Could you clarify to me if these drafts fit in our current charter >> and >> how? >>> (just to be clear, we can have presentations that don't fit in our >> charter, but it >>> is importnat to understand what the purpose of the docuemnt is) >>> >>> Regards, marcelo >>> >>> >>> El 06/07/11 21:52, Georgios Karagiannis escribió: >>>> Hi Marcelo, >>>> >>>> Is it possible to get a 10 minutes agenda slot for each of the two >>>> below >>>> dafts: >>>> >>>> http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion- >> cal >>>> culation/ >>>> >>>> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure- >> 01. >>>> txt >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> >>>> >>>> On 7/6/2011, "marcelo bagnulo braun" wrote: >>>> >>>>> The draft agenda is posted. >>>>> http://www.ietf.org/proceedings/81/agenda/conex.txt >>>>> Let me know if there are changes. >>>>> Regards, marcelo >>>>> >>>>> _______________________________________________ >>>>> conex mailing list >>>>> conex@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/conex >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 7 07:20: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 E81FB21F877F for ; Thu, 7 Jul 2011 07:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 Tc+w-gaoUAfW for ; Thu, 7 Jul 2011 07:20:19 -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 E2F8C21F8758 for ; Thu, 7 Jul 2011 07:20:17 -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 856DB633B1; Thu, 7 Jul 2011 16:20:16 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7506459A8A; Thu, 7 Jul 2011 16:20:16 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ken carlberg Date: Thu, 7 Jul 2011 16:20:15 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.uk> In-Reply-To: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.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: <201107071620.15953.mkuehle@ikr.uni-stuttgart.de> Cc: ConEx IETF list Subject: Re: [conex] draft-kuehlewind-conex-accurate-ecn-00 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, 07 Jul 2011 14:20:20 -0000 Hi Ken, thanks a lot for your feedback. The points your are mentioning are all very valid and we've already been discussing some of them. 1) The section 3.1.5. needs to be further extended (but we've been running out of time). But actually I've hoping that the description of the different schemes is good enough for the reader to basically fill an own table with pros and cons. Because if one provides a complete discussion, you already influence the reader to tend to a certain solution and you might prevent that new/different aspects will be regarded in a further discussion. Anyway, the goal is to have a full and detailed discussion in one of the next version which allows us to decide on the right scheme. 2) We reordered the sections actually several times. But 3.4. is actually not another option. It's an alternative, or lets say an hack, if the receiver is not supporting the new scheme. This can always be use no matter which coding will be chosen at the end. Also it's basically this one possible hack to scope with a 'classic' ECN receiver and thus the requirements doesn't apply to this mode. 3) Yes, that's true. We will add a comment here. 4) In this case we are actually only talking about the TCP mechanism. In DCCP ECN is already defined in such a way that you have the exact number of CE markings. Thus there is not even a problem. I think it's somewhere mentioned in the draft but only as a very small side-remark... Mirja On Thursday 07 July 2011 14:27:25 ken carlberg wrote: > Hi, > > I briefly read over the draft and came up with a few initial impressions > (in no particular order)... > > 1) i think the draft would be improved if there were some explicit > subsections that shouted out to the reader "strengths" and "weaknesses" of > each approach. Section 3.1.5 gives a brief hint of what the reader should > consider, and each of the first three sections has a "discussion". But in > reading the various approaches, I have to dig around and write on a > separate paper what characteristics I need to be aware of in comparing one > to the other. I see that you have a table in 3.1.5 representing a high > level comparison of the three, but I don't have a clear idea of what you > consider complex, accurate, or timely. In a future version, you may want > to consider presenting the options as: x.1 Description > x.2 Strength > x.3 Weakness > > And then in a following section, you can make a more detailed discussion of > the different approaches -- e.g., expanding on the table of 3.1.5. In my > opinion, by stating up front what the authors/editors perceive is the > strength and weakness of each, the reader can add further comment to help > refine the decision to a single approach. Afterwards, when one approach is > agreed upon, then perhaps you can either remove the perceived > strength/weakness or move it to an appendix. > > 2) for a lack of a better description, some of the sections seem to be > mis-numbered in terms of a hierarchy and collection of sections. It seems > odd that section 3.4 (Advanced Compatibility Mode) is separated from the > other three options of 1-bit, 3-bit, and code-point sections. All of these > options are meant to provide more reliability, and so any comparison that > you do in 3.1.5 would also seem to demand a comparison of 3.4 > > Also, shouldn't the Requirements of 3.1.1 pertain to all of the options of > 3.1.2, 3.1.3, 3.1.4, and 3.4? And so, should the requirements section be > at a section level about the different options? > > I'll stress that this comment is more of a nit, but it would be helpful to > re-organize these sections for a better flow and cleaner presentation of > the points you want to make. > > 3) In the Discussion part of each of the options, you bring up the impact > of the potential loss of ACKs to congestion. I think you should make it > clear to the reader that the congestion and loss you speak of concerning > the ACKs from the receiver can be expected to be unrelated to the > congestion of the downstream data packets forwarded towards the receiver. > This will be obvious to the individuals familiar with ECN, but not so much > to the general reader. > > 4) for section 3.4, if you choose to cite what is observed in ns2, I think > its important to solicit and add information about other deployed > implementations. > > 5) one very small nit. I'd recommend changing the text "...(ECN) is an > IP/TCP mechanism..." to "..(ECN) is an mechanism..". A more generic > statement about ECN that doesn't identify a specific transport protocol > would reflect the work to add ECN support to DCCP and RTP/RTCP. > > cheers, > > -ken From karagian@cs.utwente.nl Thu Jul 7 07:55:15 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 EA3811F0C3E for ; Thu, 7 Jul 2011 07:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[AWL=-1.054, 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 Wy7Mk3jQB9Q0 for ; Thu, 7 Jul 2011 07:55:15 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 35C951F0C3D for ; Thu, 7 Jul 2011 07:55:15 -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 p67ErYNR027120; Thu, 7 Jul 2011 16:53:35 +0200 (MEST) Received: from 130.89.12.129 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 07 Jul 2011 14:55:17 +0000 To: "marcelo bagnulo braun" Date: Thu, 07 Jul 2011 14:55:17 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4E15BCA4.7080503@it.uc3m.es> 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]); Thu, 07 Jul 2011 16:53:45 +0200 (MEST) Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 14:55:16 -0000 Hi Marcelo, Thanks for the answer! It was not clear to me that using DCCP as transport protocol in Conex was off-charter. Since this is the case, what I would like to do is the following: * Update these drafts using the comments that I have received so far, and for the time being stop working on these drafts until Conex rechartering! This means that it is not needed to researve agenda slots for the presentation of these drafts during the Conex meeting in Quebec. Does this make sense to you? Best regards, Georgios On 7/7/2011, "marcelo bagnulo braun" wrote: >Hi, > >the charter reads as follows: > >* An Experimental specification of a modification to TCP, for the >timely transport of congestion information from the destination to >the sender. > >So, i would say it is off charter. > >Morevoer, i believe it makes sense to focus our work on TCP right now, >since it seems to be more widely used than DCCP. > >Makes sense? > >Regards, marcelo > > >El 07/07/11 15:02, Georgios Karagiannis escribi=F3: >> Hi Marcelo, >> >> Before answering your question, can you please inform me whether solutions >> that use DCCP as transport protocol to carry congestion information >> feedbacks from the receiver to the sender is off-charter? >> >> These drafts are actually are using TFRC [RFC5348] to calculate the TCP >> throughput at the sender (implying that a transport protocol like DCCP >> should be used)! >> >> Best regards, >> Georgios >> >> >> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: donderdag 7 juli 2011 14:07 >>> To: Georgios Karagiannis >>> Cc: 'ConEx IETF list' >>> Subject: Re: [conex] Draft agenda >>> >>> Hi Georgios, >>> >>> Could you clarify to me if these drafts fit in our current charter and >> how? >>> (just to be clear, we can have presentations that don't fit in our >> charter, but it >>> is importnat to understand what the purpose of the docuemnt is) >>> >>> Regards, marcelo >>> >>> >>> El 06/07/11 21:52, Georgios Karagiannis escribi=F3: >>>> Hi Marcelo, >>>> >>>> Is it possible to get a 10 minutes agenda slot for each of the two >>>> below >>>> dafts: >>>> >>>> http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion-cal >>>> culation/ >>>> >>>> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01. >>>> txt >>>> >>>> Best regards, >>>> Georgios >>>> >>>> >>>> >>>> >>>> On 7/6/2011, "marcelo bagnulo braun" wrote: >>>> >>>>> The draft agenda is posted. >>>>> http://www.ietf.org/proceedings/81/agenda/conex.txt >>>>> Let me know if there are changes. >>>>> Regards, marcelo >>>>> >>>>> _______________________________________________ >>>>> conex mailing list >>>>> conex@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/conex >> From marcelo@it.uc3m.es Thu Jul 7 08:56:37 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 BCC4221F85C0 for ; Thu, 7 Jul 2011 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 xos+23+q5Zsg for ; Thu, 7 Jul 2011 08:56:37 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id DB45821F85BA for ; Thu, 7 Jul 2011 08:56:36 -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 DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 67A909C4F32; Thu, 7 Jul 2011 17:56:35 +0200 (CEST) Message-ID: <4E15D732.3000706@it.uc3m.es> Date: Thu, 07 Jul 2011 17:56:34 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Georgios Karagiannis References: In-Reply-To: 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.8.0.1017-18246.000 Cc: 'ConEx IETF list' Subject: Re: [conex] Draft agenda 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, 07 Jul 2011 15:56:37 -0000 wfm El 07/07/11 16:55, Georgios Karagiannis escribió: > Hi Marcelo, > > Thanks for the answer! > > It was not clear to me that using DCCP as transport protocol in Conex was > off-charter. > Since this is the case, what I would like to do is the following: > > * Update these drafts using the comments that I have received so far, and > for the time being stop working on these drafts until Conex > rechartering! This means that it is not needed to researve agenda slots > for the presentation of these drafts during the Conex meeting in Quebec. > > Does this make sense to you? > > Best regards, > Georgios > > > > On 7/7/2011, "marcelo bagnulo braun" wrote: > >> Hi, >> >> the charter reads as follows: >> >> * An Experimental specification of a modification to TCP, for the >> timely transport of congestion information from the destination to >> the sender. >> >> So, i would say it is off charter. >> >> Morevoer, i believe it makes sense to focus our work on TCP right now, >> since it seems to be more widely used than DCCP. >> >> Makes sense? >> >> Regards, marcelo >> >> >> El 07/07/11 15:02, Georgios Karagiannis escribió: >>> Hi Marcelo, >>> >>> Before answering your question, can you please inform me whether solutions >>> that use DCCP as transport protocol to carry congestion information >>> feedbacks from the receiver to the sender is off-charter? >>> >>> These drafts are actually are using TFRC [RFC5348] to calculate the TCP >>> throughput at the sender (implying that a transport protocol like DCCP >>> should be used)! >>> >>> Best regards, >>> Georgios >>> >>> >>> >>>> -----Original Message----- >>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>> Sent: donderdag 7 juli 2011 14:07 >>>> To: Georgios Karagiannis >>>> Cc: 'ConEx IETF list' >>>> Subject: Re: [conex] Draft agenda >>>> >>>> Hi Georgios, >>>> >>>> Could you clarify to me if these drafts fit in our current charter and >>> how? >>>> (just to be clear, we can have presentations that don't fit in our >>> charter, but it >>>> is importnat to understand what the purpose of the docuemnt is) >>>> >>>> Regards, marcelo >>>> >>>> >>>> El 06/07/11 21:52, Georgios Karagiannis escribió: >>>>> Hi Marcelo, >>>>> >>>>> Is it possible to get a 10 minutes agenda slot for each of the two >>>>> below >>>>> dafts: >>>>> >>>>> http://datatracker.ietf.org/doc/draft-karagiannis-conex-congestion-cal >>>>> culation/ >>>>> >>>>> http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-01. >>>>> txt >>>>> >>>>> Best regards, >>>>> Georgios >>>>> >>>>> >>>>> >>>>> >>>>> On 7/6/2011, "marcelo bagnulo braun" wrote: >>>>> >>>>>> The draft agenda is posted. >>>>>> http://www.ietf.org/proceedings/81/agenda/conex.txt >>>>>> Let me know if there are changes. >>>>>> Regards, marcelo >>>>>> >>>>>> _______________________________________________ >>>>>> conex mailing list >>>>>> conex@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Thu Jul 7 09:32:54 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 12F291F0C55 for ; Thu, 7 Jul 2011 09:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 Uv5fzJbvqw5r for ; Thu, 7 Jul 2011 09:32:52 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46B1F0C53 for ; Thu, 7 Jul 2011 09:32:52 -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); Thu, 7 Jul 2011 17:32:51 +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, 7 Jul 2011 17:32:51 +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 1310056369270; Thu, 7 Jul 2011 17:32:49 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.194.135]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67GWl1V026691; Thu, 7 Jul 2011 17:32:48 +0100 Message-Id: <201107071632.p67GWl1V026691@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 17:32:50 +0100 To: Georgios Karagiannis From: Bob Briscoe In-Reply-To: <008e01cc3c9e$cb32dfb0$61989f10$@cs.utwente.nl> References: <201107070928.p679S69A025144@bagheera.jungle.bt.co.uk> <006901cc3c93$b2350520$169f0f60$@cs.utwente.nl> <5FDC413D5FA246468C200652D63E627A0F1E349D@LDCMVEXC1-PRD.hq.netapp.com> <008e01cc3c9e$cb32dfb0$61989f10$@cs.utwente.nl> 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: 07 Jul 2011 16:32:51.0429 (UTC) FILETIME=[83CAB150:01CC3CC3] Cc: conex@ietf.org Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 16:32:54 -0000 Georgios, I don't think it's fair to describe your draft as a solution. Whatever the protocol. Whatever the congestion=20 control algorithm. It achieves precisely nothing, except warming the= processor. Your draft merely suggests a sender can calculate information it already= has... Existing situation for any transport sender: - Congestion feedback information comes in to the=20 sender at rate pX (the loss event rate). - The sender uses this to drive the algorithm=20 that determines how it changes its rate X Your proposal - The sender measures the change in the rate X=20 every RTT and from this works out what p would=20 have caused this, using the equation for its own algorithm in reverse. - from p it can work out pX, the loss event rate Results: - the sender has worked out pX, which it already knew accurately at the= start. - the CPU has got warmer. Therefore, as I said, this achieves precisely=20 nothing except increasing the amount of entropy in the Universe. Bob At 13:09 07/07/2011, Georgios Karagiannis wrote: >Hi Richard, > >You are right! The solution described in my draft only applies to transport >protocols that are using TFRC . > >So my proposal is: >Is it possible to combine our solutions, such that TCP based applications, >but also DCCP based applications can use Conex? > >Best regards, >Georgios > > > > > -----Original Message----- > > From: Scheffenegger, Richard [mailto:rs@netapp.com] > > Sent: donderdag 7 juli 2011 13:56 > > To: Georgios Karagiannis; Bob Briscoe > > Cc: conex@ietf.org > > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx > > > > Hi Georgios, > > > > > > If you choose to use formulas to estimate the transport rate, that= formula > > obviously has to apply to the transport protocol used. TFRC is= applicable >to > > DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. However, all bets > > are off for *ANY* other transport (CBR VoIP over UDP / RTP). > > > > Furthermore, each of these transports has to have some form of feedback > > mechanism from the receiver to the sender, so that the sender can= actually > > react to congestion. Thus, your scheme is implicitly completely reliant= on > > whatever feedback is available from the transport. > > > > RTP, for example, will have very extensive feedback (much more extensive > > than what TCP, SCTP, DCCP can do) - see >http://tools.ietf.org/id/draft-ietf- > > avtcore-ecn-for-rtp-00.txt > > > > > > What Bob tried to point out is exactly that - your method applies a >specific, > > post-hoc method. This method implicitly relies on transport feedback > > already, but then simply appears to stuff all transports into a >TCP-friendly > > corset, which may not applicable at all. > > > > > > The goal of our drafts (accurate-ecn and conex-tcp-mods) is to address= the > > critical part, where the transport receiver gives the *appropriate* (not >some > > estimated) congestion information back to the transport sender. With= TCP, > > we are unfortunately very constrained due to the very widespread use= (and > > also because TCP processing is poured into hardware these days), which > > severly limits what can be done in a backwards-compatible way. > > > > Best regards, > > > > Richard Scheffenegger > > > > NetApp > > rs@netapp.com > > +43 1 3676811 3146 Office (2143 3146 - internal) > > +43 676 654 3146 Mobile > > www.netapp.com > > > > EURO PLAZA > > Geb=E4ude G, Stiege 7, 3.OG > > Am Euro Platz 2 > > A-1120 Wien > > > > > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Donnerstag, 07. Juli 2011 12:51 > > > To: 'Bob Briscoe' > > > Cc: conex@ietf.org > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > > > Hi Bob, > > > > > > > > > Please see in line! > > > > > > > > > > -----Original Message----- > > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > > Sent: donderdag 7 juli 2011 11:28 > > > > To: Georgios Karagiannis > > > > Cc: conex@ietf.org > > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx > > > > > > > > Georgios, > > > > > > > > >On 7/7/2011, "Georgios Karagiannis" wrote: > > > > > >Regarding the beyond reasoning statement, it is better to not > > > discuss > > > > > >it via email, but face to face. Will you be in Quebec during the > > > next > > > > > >IETF meeting? > > > > > > > > I meant that your response was not engaging in the reasoning put to > > > you. > > > > > > > > You can go back and respond to the reasoning already given. But I > > > don't > > > need > > > > to say any more. > > > > > > > > My main point was that the whole idea of your draft goes round in a > > > loop > > > > that achieves nothing. > > > > You avoided this critical point and jumped to a detail (a detail > > > within > > > that loop > > > > that already achieves nothing). > > > > > > Georgios: I am not sure if this loop applies to what is written in my > > > draft. > > > > > > > > > > > Now you are saying you meant something very different to what you > > > > had written (you now say the draft was about DCCP, but the title of > > > > your > > > draft > > > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP takes > > > you > > > off- > > > > charter instead (see below). > > > > > > In the drafts I had not yet specified which transport protocol should > > > be used, what I have specified was that the congestion exposure can be > > > calculated using the TCP throughput formula used in TFRC (RFC5348). > > > And according to [RFC5348] "TFRC is a congestion control mechanism > > > designed for unicast flows operating in > > > an Internet environment and competing with TCP traffic [FHPW00]. > > > Instead of specifying a complete protocol, this document simply > > > specifies a congestion control mechanism that could be used in a > > > transport protocol such as DCCP (Datagram Congestion Control > > > Protocol) [RFC4340], in an application incorporating end-to-end > > > congestion control at the application level, or in the context of > > > endpoint congestion management [BRS99].", from [RFC5348]. > > > > > > So I do not think that I was saying something in the previous email > > > that is different than what is stated in my draft. > > > > > > > > > > > > > > At 07:08 07/07/2011, Georgios Karagiannis wrote: > > > > >Do you mean that is off-charter because is using for feedback DCCP > > > > >& TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? > > > > > > > > Yes. > > > > > > > > ConEx is primarily at the IP layer, but some transports need > > > > optional > > > changes > > > > to their feedback. The charter says we will focus on TCP first. > > > > > > Georgios: In the charter the following is mentioned: > > > "Today, the network may signal > > > congestion by ECN markings or by dropping packets, and the receiver > > > passes this information back to the sender in transport-layer > > > acknowledgements. The mechanism to be developed by the CONEX WG > > will > > > enable the sender to also relay the congestion information back into > > > the network in-band at the IP layer, such that the total level of > > > congestion is visible to all IP devices along the path, from where it > > > could, for example, be provided as input to traffic management." , > > > from [Conex charter] > > > > > > > > > Further down the charter mentions: > > > > > > "Primary work items are: > > > > > > * An Informational document containing an abstract description of the > > > congestion exposure mechanism that is independent of specific > > > transport protocols and congestion information encoding techniques > > > needed for different IP protocol versions. > > > > > > * An Experimental specification of an IPv6 packet structure that > > > encapsulates CONEX information, defining a packet format and an > > > interpretation. > > > > > > > > > * An Experimental specification of a modification to TCP, for the > > > timely transport of congestion information from the destination to the > > > sender.", from [Conex charter] > > > > > > > > > By reading the first paragraph from above, I can understand that > > > Conex WG will use transport-layer acknowledgement to pass the > > > congestion information (signalled by ECN markings or by dropping > > > packets to the receiver) from the receiver to the sender. > > > Thus any types of transport protocols can be used for this purpose > > > (e.g., TCP, DCCP). > > > > > > > > > By reading the third bullet from above, I can understand that the > > > CONEX WG will primarily focus on TCP. > > > > > > However, to my understanding this does not imply that other types of > > > transport protocols, e.g. ., DCCP, are off-charter. This is in my > > > opinion not explicitly mentioned in the charter. > > > > > > Could the WG chairs comment on this issues, see below: > > > > > > Conex needs transport protocols to carry congestion information from a > > > receiver to a sender. > > > Are transport protocols such as DCCP out of the Conex charter scope? > > > > > > > > > > > You are criticising a draft written to satisfy this charter > > > objective. You > > > are > > > > saying it is difficult to change the semantics of TCP header fields > > > (which > > > we > > > > are already chartered to do). So you propose everyone should have to > > > use > > > > DCCP in order to use ConEx. That would require every application in > > > the > > > > world that uses TCP to be changed to call DCCP instead, in order to > > > use > > > > ConEx. And most middleboxes (NATs, firewalls) would have to be > > > changed > > > > too. > > > > > > Georgios: Sorry Bob, but this is your interpretation. > > > > > > Another interpretation could be: > > > It is good to provide the means such that Conex is used in combination > > > with applications that are using not only TCP as a transport protocol, > > > but also the ones that are using DCCP as transport protocol. > > > Furthermore, start with a solution to calculate congestion, in this > > > case the TFRC [RF5348], that is simple and does not imply many > > > standardization changes on the transport protocols using this > > > solution. > > > Moreover, note that I am in favour that a TCP based transport solution > > > should be specified in parallel. > > > > > > Best regards, > > > Georgios > > > > > > > > > _______________________________________________ > > > 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 Jul 7 10:45: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 8FFF31F0C61 for ; Thu, 7 Jul 2011 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 Sl6PmQgVQZzP for ; Thu, 7 Jul 2011 10:45:33 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 86EC21F0C52 for ; Thu, 7 Jul 2011 10:45:32 -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, 7 Jul 2011 18:45:30 +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, 7 Jul 2011 18:45:30 +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 1310060729403; Thu, 7 Jul 2011 18:45:29 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.80.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67HjRgp026963; Thu, 7 Jul 2011 18:45:27 +0100 Message-Id: <201107071745.p67HjRgp026963@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 18:45:18 +0100 To: From: Bob Briscoe In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.doma in1.systemhost.net> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> 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: 07 Jul 2011 17:45:30.0800 (UTC) FILETIME=[AA2DEB00:01CC3CCD] Cc: conex@ietf.org Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 07 Jul 2011 17:45:34 -0000 Phil, Thanks - v useful feedback. The only reason for having use-cases under "other" was so we don't have interminable arguments again about which use-cases to include. We've already decided (I think) not to include these use-cases in order to keep the draft focused, so readers go away with one message not hundreds. But as there's still pressure to have different use-cases, I thought just mentioning them briefly would be a good compromise. I had already picked up your earlier comment about making use-cases 1,2,3 follow on from each other, rather than appear independent. Flagging that in the headings is a good idea. more inline... At 14:13 07/07/2011, philip.eardley@bt.com wrote: >Bob, > >On the Use cases, I'd say something like:- > >Conex enables IP nodes to see information about the whole path >congestion, so that it is visible as a useful metric; some of the >use cases thereby enabled are: >(1) Inform the operator's traffic management >(2) Side impact - incentivise scavenger transports >(3) Side impact - enable enduser-controlled QoS >(4) Inform the operator's provisioning process >(5) Inform the interconnect agreement between two operators > >- i deliberately included the first sentence [before the list]. I >think it's important to be clear about what the conex capability is, >as these are cases that use that capability. (this may also help >clarify what other stuff is needed by a particular use case) I was going to put some text between 5. and 5.1 to explain the likely sequence of events. So this can go there. >- i think it's much clearer to say what conex directly enables (1, >4, 5) and what it, as a side effect, encourages to happen (2, 3). I >think it's helpful to have 'Side impact' in the section title. 'Side impact' sounds a bit off-hand tho. I'll probably use "Consequence" >- i think my 3 is the same as your 'intra-class QoS', but is of >slightly wider scope & also makes it clearer that it's interesting >for the end user. Anyway, what i mean is the flip side of (2) - >enable the-opposite-of-scavenger transports. I'll use "Consequence: User-Controlled Intra-Class QoS" I agree headings are important. Intra-class QoS was to make it clear this doesn't threaten vendor's Diffserv products, which has caused knee-jerk allergic reactions in the past. >- 'accounting for congestion' is already covered within (1). The >text in S5.3 of the I-D (current version, -01) is slightly >philosophical about what things would be like if everyone used >conex. I dont think it's needed. If you really want it, how about a >section towards the end of the doc that covers longer-terms vision >etc. Anyway, it doesnt read like a use case to me. I only kept it because I assumed the w-g wanted it. I also think it's rather whimsical. Given it was actually about an ideal global deployment, I would be happy to replace it with a less ambitious "Inform Inter-Operator Contracts" section, without implying global deployment. >- personally i think that (4) is important enough it shouldn't be >hidden as a sub-case See above - avoid confusing the single main message. >- (5) is a bit trickier, as it requres 2 operators to be using >conex. Personally i'd prefer to show it as a use case, rather than >hide it in 'other use cases' Ditto. We want to leave the message that this would be useful for one network to do unilaterally (to get started). Demoting interconnection to "other" helps that without losing it. >- i think it's important to get the wording of the section titles >right. Eg "Provisioning capacity" is poor (something like " Inform >the operator's provisioning process" is better). Would "Inform Capacity Provisioning" be acceptable? Pretty obvious this is the operator's and that it's a process. >- re " Preventing congestion collapse" - this fails the previous >comment. Anyway, it sounds more like a possible benefit than a use >case. Dont think it's needed. It's a Consequence of traffic management. Use-cases /are/ benefits from using ConEx. By your rules it would be "Consequence: Operator can Prevent Congestion Collapse" (In text I was planning on saying: The Internet is no less vulnerable to congestion collapses now than it was in the 1980s [ref]. If a new app that implemented congestion control badly rapidly became popular, existing non-congestion-related traffic controls would not prevent collapse. Under extreme congestion, ConEx-based traffic management would automatically override host congestion control and prevent collapse. ) >- re " Mitigating flooding attacks". I suspect not mentioning is the >pragmatic approach. Yup. >Other comments: >'concepts' rather than 'definitions' is great. The current page >count in the ToC suggests you only have text under 'definitions'. >Suggest you work as much as possible, ie describe the concepts! > >'Deployment arrangements' - much better >'self congestion' - agree. Cheers Bob >Thanks, >phil > > > >-----Original Message----- >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >Behalf Of Bob Briscoe >Sent: 06 July 2011 11:57 >To: ConEx IETF list >Subject: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC > >ConEx folks, > >The proposed table of contents for draft-02 is pasted at the end. >Please react if you object. There will be controversy, but please try >to recognise that we ought to be converging now. > >Here's the rationale for the changes. > >2. Definitions -> Concepts > >The "Definitions" section in draft-01 actually introduced the main >concepts, which is goal #1 of this doc. So Concepts is a better >section heading. >Then we've added the much-discussed Misconceptions sub-section >clarifying it's not misconceptions about networking, just about ConEx. > >5. ConEx Use Cases >Removed one use-case (Accounting for Congestion Volume) but really >just moved it to "Other Use-Cases" so it can be much shorter. > >Under "Other Use-Cases", we propose very brief bullets on each of: >* Preventing congestion collapse >* Accounting for congestion >* Interconnection traffic contracts >* Provisioning capacity > >The idea is to resolve all the to-and-fro about which use-cases >should be in or out, by having a "half-in" category. > >And possibly (controversial!) we could then even add... >* Mitigating flooding attacks > >Note also the change of heading: > 5.3. ConEx for Intra-Class Quality of Service (QoS) >We'll change the story to emphasise that ConEx doesn't replace >Diffserv, but it could handle allocation of resources within a class >(ie bandwidth allocation as opposed to queue scheduling). > >6. Deployment Arrangements. > >Replaces previous S.5.5. Partial vs. Full Deployment > >It's tough to talk about deployment in a mechanism-neutral way (given >deployment is about deploying mechanisms!). Nonetheless, the idea is >to give a plausible story for how the previously mentioned use-cases >would get incrementally deployed. So it fits in this doc, but it will >be tough. We have summarised stuff about components and incremental >deployment in abstract-mech first (I intend to post proposed new text >for this section to the list shortly). > >7.2. Self Congestion > >Rather than diving straight into this detailed area early in the >Introduction, we've moved it to where it belongs: under 7. Potential Issues. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.2. Common Misconceptions about ConEx . . . . . . . . . . . . 7 > 3. Traffic Management . . . . . . . . . . . . . . . . . . . . . . 7 > 3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 8 > 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 9 > 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 10 > 5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11 > 5.1. ConEx as a basis for traffic management . . . . . . . . . 11 > 5.2. ConEx to incentivise scavenger transports . . . . . . . . 11 > 5.3. ConEx for Intra-Class Quality of Service (QoS) . . . . . . 12 > 5.4. Other Use-Cases . . . . . . . . . . . . . . . . . . . . . 13 > 6. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 13 > 6.1. Deployment Concepts . . . . . . . . . . . . . . . . . . . 13 > 6.2. Single Receiving Network Scenario . . . . . . . . . . . . 14 > 6.3. Other Initial Deployment Scenarios . . . . . . . . . . . . 14 > 7. Potential Issues . . . . . . . . . . . . . . . . . . . . . . . 14 > 7.1. Congestion as a Commercial Secret . . . . . . . . . . . . 14 > 7.2. Self Congestion . . . . . . . . . . . . . . . . . . . . . 15 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 > 8.1. Information Security . . . . . . . . . . . . . . . . . . . 16 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 > 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 > 11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 18 > 12. Informative References . . . . . . . . . . . . . . . . . . . . 18 > Appendix A. Changes from previous drafts (to be removed by > the RFC Editor) . . . . . . . . . . . . . . . . . . . 19 >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >Cheers > >Bob (& discussed with Rich as co-editor, but still some uncertainties >- hence asking the list for views) > > >Bob > > > >________________________________________________________________ >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 Jul 7 11:20: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 3A5341F0C88 for ; Thu, 7 Jul 2011 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 UKIkBDUZLZWg for ; Thu, 7 Jul 2011 11:20:48 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9CF1F0C81 for ; Thu, 7 Jul 2011 11:20:47 -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, 7 Jul 2011 19:20:46 +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, 7 Jul 2011 19:20:46 +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 1310062844780; Thu, 7 Jul 2011 19:20:44 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.80.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67IKgRx027077; Thu, 7 Jul 2011 19:20:42 +0100 Message-Id: <201107071820.p67IKgRx027077@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 19:20:45 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= , ken carlberg From: Bob Briscoe In-Reply-To: <201107071620.15953.mkuehle@ikr.uni-stuttgart.de> References: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.uk> <201107071620.15953.mkuehle@ikr.uni-stuttgart.de> 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: 07 Jul 2011 18:20:46.0292 (UTC) FILETIME=[971C6140:01CC3CD2] Cc: ConEx IETF list Subject: Re: [conex] draft-kuehlewind-conex-accurate-ecn-00 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, 07 Jul 2011 18:20:49 -0000 Mirja, Ken, Mirja =3D Ken's objection #5) (your 4) was because=20 you described ECN as an IP/TCP mechanism, not=20 because you described your draft as only about TCP. I support Ken's point. Ken =3D Bear in mind that the 3 options in this=20 draft are intended to support a process whereby=20 one day we choose one and demote the others. So I=20 would doc suggest the structure is designed for=20 when this becomes a protocol spec, rather than a=20 discussion of options for one of the functions. Bob At 15:20 07/07/2011, Mirja K=FChlewind wrote: >Hi Ken, > >thanks a lot for your feedback. The points your are mentioning are all very >valid and we've already been discussing some of them. > >1) The section 3.1.5. needs to be further=20 >extended (but we've been running out >of time). But actually I've hoping that the description of the different >schemes is good enough for the reader to basically fill an own table with >pros and cons. Because if one provides a complete discussion, you already >influence the reader to tend to a certain solution and you might prevent= that >new/different aspects will be regarded in a further discussion. >Anyway, the goal is to have a full and detailed discussion in one of the= next >version which allows us to decide on the right scheme. > >2) We reordered the sections actually several times. But 3.4. is actually= not >another option. It's an alternative, or lets say an hack, if the receiver= is >not supporting the new scheme. This can always be use no matter which= coding >will be chosen at the end. Also it's basically this one possible hack to >scope with a 'classic' ECN receiver and thus the requirements doesn't apply >to this mode. > >3) Yes, that's true. We will add a comment here. > >4) In this case we are actually only talking about the TCP mechanism. In= DCCP >ECN is already defined in such a way that you have the exact number of CE >markings. Thus there is not even a problem. I think it's somewhere= mentioned >in the draft but only as a very small side-remark... > >Mirja > > >On Thursday 07 July 2011 14:27:25 ken carlberg wrote: > > Hi, > > > > I briefly read over the draft and came up with a few initial impressions > > (in no particular order)... > > > > 1) i think the draft would be improved if there were some explicit > > subsections that shouted out to the reader "strengths" and "weaknesses"= of > > each approach. Section 3.1.5 gives a brief hint of what the reader= should > > consider, and each of the first three sections has a "discussion". But= in > > reading the various approaches, I have to dig around and write on a > > separate paper what characteristics I need to be aware of in comparing= one > > to the other. I see that you have a table in 3.1.5 representing a high > > level comparison of the three, but I don't have a clear idea of what you > > consider complex, accurate, or timely. In a future version, you may= want > > to consider presenting the options as: x.1 Description > > x.2 Strength > > x.3 Weakness > > > > And then in a following section, you can make a more detailed discussion= of > > the different approaches -- e.g., expanding on the table of 3.1.5. In= my > > opinion, by stating up front what the authors/editors perceive is the > > strength and weakness of each, the reader can add further comment to= help > > refine the decision to a single approach. Afterwards, when one approach= is > > agreed upon, then perhaps you can either remove the perceived > > strength/weakness or move it to an appendix. > > > > 2) for a lack of a better description, some of the sections seem to be > > mis-numbered in terms of a hierarchy and collection of sections. It= seems > > odd that section 3.4 (Advanced Compatibility Mode) is separated from the > > other three options of 1-bit, 3-bit, and code-point sections. All of= these > > options are meant to provide more reliability, and so any comparison= that > > you do in 3.1.5 would also seem to demand a comparison of 3.4 > > > > Also, shouldn't the Requirements of 3.1.1 pertain to all of the options= of > > 3.1.2, 3.1.3, 3.1.4, and 3.4? And so, should the requirements section= be > > at a section level about the different options? > > > > I'll stress that this comment is more of a nit, but it would be helpful= to > > re-organize these sections for a better flow and cleaner presentation of > > the points you want to make. > > > > 3) In the Discussion part of each of the options, you bring up the= impact > > of the potential loss of ACKs to congestion. I think you should make it > > clear to the reader that the congestion and loss you speak of concerning > > the ACKs from the receiver can be expected to be unrelated to the > > congestion of the downstream data packets forwarded towards the= receiver. > > This will be obvious to the individuals familiar with ECN, but not so= much > > to the general reader. > > > > 4) for section 3.4, if you choose to cite what is observed in ns2, I= think > > its important to solicit and add information about other deployed > > implementations. > > > > 5) one very small nit. I'd recommend changing the text "...(ECN) is an > > IP/TCP mechanism..." to "..(ECN) is an mechanism..". A more generic > > statement about ECN that doesn't identify a specific transport protocol > > would reflect the work to add ECN support to DCCP and RTP/RTCP. > > > > cheers, > > > > -ken > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From carlberg@g11.org.uk Thu Jul 7 11:31: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 976C821F8589 for ; Thu, 7 Jul 2011 11:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxGXQlL85Pjq for ; Thu, 7 Jul 2011 11:31:32 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 825E921F858F for ; Thu, 7 Jul 2011 11:31:32 -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=hP7uriS1BbmLwDD7eACgB2/5NOE64ByEYDfFtcdE2byJOGO/kTf3jF4yGtQffw/A0JW7artKJrbNw8jc9sceUy+0nFTgr9U3XUrnfkGJD+TIhb8gspdzFuXAvXPSi3xv; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:52019 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1QetM9-0005Q5-2b; Thu, 07 Jul 2011 18:31:21 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201107071820.p67IKgRx027077@bagheera.jungle.bt.co.uk> Date: Thu, 7 Jul 2011 14:31:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FDA00B4-27B0-4861-A18F-3E97BAB8A07F@g11.org.uk> References: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.uk> <201107071620.15953.mkuehle@ikr.uni-stuttgart.de> <201107071820.p67IKgRx027077@bagheera.jungle.bt.co.uk> To: Bob Briscoe 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] draft-kuehlewind-conex-accurate-ecn-00 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, 07 Jul 2011 18:31:33 -0000 On Jul 7, 2011, at 2:20 PM, Bob Briscoe wrote: > Ken =3D Bear in mind that the 3 options in this draft are intended to = support a process whereby one day we choose one and demote the others. = So I would doc suggest the structure is designed for when this becomes a = protocol spec, rather than a discussion of options for one of the = functions. ok, then I was a bit confused. I was under the impression that one of = the options would be chosen *during* the progression of the draft. If = all options (and possibly others that some may recommend) will remain, = then I think this needs to be made more clear in the draft. (And now I = can more easily understand Mirja's desire not to influence an option = before its been "experimented" with.) but this also puts more importance in articulating the characteristics = by which each is examined -- ie, what constitutes complexity, what = determines efficiency, what measure of fault tolerance exists, blah, = blah, blah. -ken From bob.briscoe@bt.com Thu Jul 7 11:39: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 1271F1F0C65 for ; Thu, 7 Jul 2011 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 Grhpkq8Qzkmk for ; Thu, 7 Jul 2011 11:38:59 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 42D631F0C55 for ; Thu, 7 Jul 2011 11:38: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); Thu, 7 Jul 2011 19:38: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); Thu, 7 Jul 2011 19:38:57 +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 131006393746; Thu, 7 Jul 2011 19:38:57 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.80.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67Ictmu027135; Thu, 7 Jul 2011 19:38:56 +0100 Message-Id: <201107071838.p67Ictmu027135@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 19:38:57 +0100 To: ken carlberg From: Bob Briscoe In-Reply-To: <1FDA00B4-27B0-4861-A18F-3E97BAB8A07F@g11.org.uk> References: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.uk> <201107071620.15953.mkuehle@ikr.uni-stuttgart.de> <201107071820.p67IKgRx027077@bagheera.jungle.bt.co.uk> <1FDA00B4-27B0-4861-A18F-3E97BAB8A07F@g11.org.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: 07 Jul 2011 18:38:57.0880 (UTC) FILETIME=[21BF7D80:01CC3CD5] Cc: ConEx IETF list Subject: Re: [conex] draft-kuehlewind-conex-accurate-ecn-00 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, 07 Jul 2011 18:39:00 -0000 Ken, SOrry. I meant the same as what you thought. Demote = kick out. Except I was trying to allow for the possibility we leave some vestige of text in an appendix to exaplin what we didn't do and why not. Bob At 19:31 07/07/2011, ken carlberg wrote: >On Jul 7, 2011, at 2:20 PM, Bob Briscoe wrote: > > > Ken = Bear in mind that the 3 options in this draft are intended > to support a process whereby one day we choose one and demote the > others. So I would doc suggest the structure is designed for when > this becomes a protocol spec, rather than a discussion of options > for one of the functions. > > >ok, then I was a bit confused. I was under the impression that one >of the options would be chosen *during* the progression of the >draft. If all options (and possibly others that some may recommend) >will remain, then I think this needs to be made more clear in the >draft. (And now I can more easily understand Mirja's desire not to >influence an option before its been "experimented" with.) > >but this also puts more importance in articulating the >characteristics by which each is examined -- ie, what constitutes >complexity, what determines efficiency, what measure of fault >tolerance exists, blah, blah, blah. > >-ken ________________________________________________________________ Bob Briscoe, BT Innovate & Design From carlberg@g11.org.uk Thu Jul 7 11:42: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 C27DE1F0C61 for ; Thu, 7 Jul 2011 11:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 YrEIY3c4mPIh for ; Thu, 7 Jul 2011 11:42:05 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAE1F0C55 for ; Thu, 7 Jul 2011 11:42:05 -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=h4zYhVNyDARcxAhiTebZj4A0eUtzLKI18gKcgQaqsfGpKjCX6IXfNOX73WqaHmzLpZ1AMsOz9+cOL31n4w5zN0IWtmKPdX9ZvOnMAASxR7MK8U0HDQHQk5fmMps63Xry; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:52043 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1QetWN-0006jw-E7; Thu, 07 Jul 2011 18:41:55 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201107071838.p67Ictmu027135@bagheera.jungle.bt.co.uk> Date: Thu, 7 Jul 2011 14:42:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <146F523B-C249-4F5B-81D0-956D56B51248@g11.org.uk> References: <24A2455B-0206-4865-B25B-200BD2C4CCE9@g11.org.uk> <201107071620.15953.mkuehle@ikr.uni-stuttgart.de> <201107071820.p67IKgRx027077@bagheera.jungle.bt.co.uk> <1FDA00B4-27B0-4861-A18F-3E97BAB8A07F@g11.org.uk> <201107071838.p67Ictmu027135@bagheera.jungle.bt.co.uk> To: Bob Briscoe 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] draft-kuehlewind-conex-accurate-ecn-00 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, 07 Jul 2011 18:42:06 -0000 ah, ok. Works for me. cheers, -ken On Jul 7, 2011, at 2:38 PM, Bob Briscoe wrote: >=20 > Ken, >=20 > SOrry. I meant the same as what you thought. Demote =3D kick out. >=20 > Except I was trying to allow for the possibility we leave some vestige = of text in an appendix to exaplin what we didn't do and why not. >=20 >=20 > Bob >=20 > At 19:31 07/07/2011, ken carlberg wrote: >=20 >> On Jul 7, 2011, at 2:20 PM, Bob Briscoe wrote: >>=20 >> > Ken =3D Bear in mind that the 3 options in this draft are intended = to support a process whereby one day we choose one and demote the = others. So I would doc suggest the structure is designed for when this = becomes a protocol spec, rather than a discussion of options for one of = the functions. >>=20 >>=20 >> ok, then I was a bit confused. I was under the impression that one = of the options would be chosen *during* the progression of the draft. = If all options (and possibly others that some may recommend) will = remain, then I think this needs to be made more clear in the draft. = (And now I can more easily understand Mirja's desire not to influence an = option before its been "experimented" with.) >>=20 >> but this also puts more importance in articulating the = characteristics by which each is examined -- ie, what constitutes = complexity, what determines efficiency, what measure of fault tolerance = exists, blah, blah, blah. >>=20 >> -ken >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From bob.briscoe@bt.com Thu Jul 7 12:25: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 70E6621F88E4 for ; Thu, 7 Jul 2011 12:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 NlOMTtzpttpm for ; Thu, 7 Jul 2011 12:25:41 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6954721F88CB for ; Thu, 7 Jul 2011 12:25:41 -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); Thu, 7 Jul 2011 20:25:39 +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, 7 Jul 2011 20:25:39 +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 1310066738259; Thu, 7 Jul 2011 20:25:38 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.80.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p67JPZY0027277; Thu, 7 Jul 2011 20:25:36 +0100 Message-Id: <201107071925.p67JPZY0027277@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jul 2011 20:25:39 +0100 To: From: Bob Briscoe In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D33C5D@EMV65-UKRD.doma in1.systemhost.net> References: <201107062341.p66NfL4j023107@bagheera.jungle.bt.co.uk> <4E156612.5030409@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32E2D33C5D@EMV65-UKRD.domain1.systemhost.net> 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: 07 Jul 2011 19:25:39.0446 (UTC) FILETIME=[A79C8960:01CC3CDB] Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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, 07 Jul 2011 19:25:42 -0000 Phil & all, I've decided the question & answer style broke up the flow. So here it is re-written in prose and much shorter cos I've cut out chunks that weren't really nec (e.g. utilisation != congestion)... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 2.2. Non-Goals of ConEx and Common Misconceptions Congestion exposure is about the transport sender exposing congestion to the network, not the other way round. That would not make sense given by design the transport endpoints handle congestion in the TCP/IP protocol suite. Nonetheless, it is a non-goal for IP layer devices to use this ConEx information to do fine-grained congestion control. That is still best done at the transport sender. There is also no expectation that the information will be used by every IP router and forwarding device. More likely, specific ConEx-based functions like traffic management will be added to edge routers. This in turn should incentivize end-system transports to be more careful about congesting others. Note that good behaviour at individual flow granularity is the intended outcome, not the forcing function--it is the end, not the means. Enforcing per-flow compliance to the TCP congestion response (or any per-flow rate enforcement) is a non-goal: o It used to be commonly believed that TCP-friendliness was critical to fairness on the Internet. However, a particular congestion control algorithm doesn't determine how much data an application transfers, or how many flows it opens, or which congestion control algorithm an application uses, or how many applications the user runs, or how many users are active at once. These factors all have a stronger impact on how great a share of a link is available for any particular data transfer. To achieve fairness at this broader granularity (between users, homes, sites or whole networks) requires that individual flows in the same bottleneck will sometimes be very unequal. o If the network forced everything to be TCP-friendly, some important applications would not work. Worse still, this would prevent deployment of higher performance replacements to TCP. It is important to allow give and take between one user's flows: some Briscoe & Woundy Expires January 5, 2012 [Page 7] Internet-Draft ConEx Mechanism July 2011 can be more aggressive than TCP and others less, e.g. long transfers, following the example of LEDBAT [LEDBAT] (see Section 5.2). Therefore, network enforcement of per-flow fairness is not only a non-goal, it would be a harmful goal in many respects. Capacity provisioning in relation to ConEx is another area of confusion. Congestion-based traffic management is not an alternative to good capacity provisioning. Either or both can be good practice depending on the situation, and ConEx can provide a useful metric for both (see Section 5.4). However, removing congestion from _all_ parts of a network is unlikely to be a goal. If an end-to-end transport protocol cannot go fast enough to cause congestion somewhere along the path, it is probably broken. A good transport protocol will continue to accelerate until it encounters a bottleneck--typically in an access network (or all too often in the receiver's buffer, but that's another story). Low levels of congestion _somewhere_ are therefore healthy. Just to be clear though, zero congestion somewhere (e.g. the core) is also perfectly healthy. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ At 13:34 07/07/2011, philip.eardley@bt.com wrote: >Your suggestions look good. >Personally would put them later. A good, simple explanation of what >conex is about should reduce the chances of a reader being >misconceived. You could always put an advert early in the doc > >Cong & utilisation - would make this a question in its own right. >I'd expand it a bit. Explain how acting assuming it's one (& in fact >it's the other) leads to wrong 'cures'. > >Network traffic mgt does congestion control? - the bullet could be >clearer. TM can be on just as fast timescales as cong control. the >"arbitrate overall fairness" point is only one possibility for how >TM can use conex info (& the next bullet explains that case) > >I'm not sure the first question is quite right, but am not inspired >with an alternative at the moment > > >-----Original Message----- ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Thu Jul 7 12:56: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 C479C11E80B1 for ; Thu, 7 Jul 2011 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.859 X-Spam-Level: X-Spam-Status: No, score=0.859 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 w66UQ58ZeSEI for ; Thu, 7 Jul 2011 12:56:26 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 19A7121F857F for ; Thu, 7 Jul 2011 12:56:07 -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 p67JsR0F004070; Thu, 7 Jul 2011 21:54:27 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 07 Jul 2011 19:56:10 +0000 To: "Bob Briscoe" Date: Thu, 07 Jul 2011 19:56:09 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107071632.p67GWl1V026691@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]); Thu, 07 Jul 2011 21:54:39 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] New draft(s) on TCP modifications for ConEx 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, 07 Jul 2011 19:56:27 -0000 Hi Bob, The goal of the solution provided in my I-D is that TFRC is used to calculate the congestion exposure rate in a much simpler manner than the one proposed by Re-ECN. The calculated congestion rate will be then exposed into the IP network in a similar way as described in the "conex-abstract-meth". Richard already mentioned that by using TFRC the congestion exposure rate can be calculated much easier than I thought. Thus instead of calculating the congestion exposure rate from the TCP throughput, one can just calculate that from the received pX directly. So my congestion exposure solution is much much simpler than I thought. Thus Richard thanks for this hint! These changes will be included in the next version of the draft. Best regards, Georgios On 7/7/2011, "Bob Briscoe" wrote: >Georgios, > >I don't think it's fair to describe your draft as a solution. >Whatever the protocol. Whatever the congestion=20 >control algorithm. It achieves precisely nothing, except warming the process= or. > >Your draft merely suggests a sender can calculate information it already has= .. > > >Existing situation for any transport sender: >- Congestion feedback information comes in to the=20 >sender at rate pX (the loss event rate). >- The sender uses this to drive the algorithm=20 >that determines how it changes its rate X > >Your proposal >- The sender measures the change in the rate X=20 >every RTT and from this works out what p would=20 >have caused this, using the equation for its own algorithm in reverse. >- from p it can work out pX, the loss event rate > >Results: >- the sender has worked out pX, which it already knew accurately at the star= t. >- the CPU has got warmer. > >Therefore, as I said, this achieves precisely=20 >nothing except increasing the amount of entropy in the Universe. > > > >Bob > >At 13:09 07/07/2011, Georgios Karagiannis wrote: >>Hi Richard, >> >>You are right! The solution described in my draft only applies to transport >>protocols that are using TFRC . >> >>So my proposal is: >>Is it possible to combine our solutions, such that TCP based applications, >>but also DCCP based applications can use Conex? >> >>Best regards, >>Georgios >> >> >> >> > -----Original Message----- >> > From: Scheffenegger, Richard [mailto:rs@netapp.com] >> > Sent: donderdag 7 juli 2011 13:56 >> > To: Georgios Karagiannis; Bob Briscoe >> > Cc: conex@ietf.org >> > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx >> > >> > Hi Georgios, >> > >> > >> > If you choose to use formulas to estimate the transport rate, that formu= la >> > obviously has to apply to the transport protocol used. TFRC is applicabl= e >>to >> > DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. However, all bets >> > are off for *ANY* other transport (CBR VoIP over UDP / RTP). >> > >> > Furthermore, each of these transports has to have some form of feedback >> > mechanism from the receiver to the sender, so that the sender can actual= ly >> > react to congestion. Thus, your scheme is implicitly completely reliant = on >> > whatever feedback is available from the transport. >> > >> > RTP, for example, will have very extensive feedback (much more extensive >> > than what TCP, SCTP, DCCP can do) - see >>http://tools.ietf.org/id/draft-ietf- >> > avtcore-ecn-for-rtp-00.txt >> > >> > >> > What Bob tried to point out is exactly that - your method applies a >>specific, >> > post-hoc method. This method implicitly relies on transport feedback >> > already, but then simply appears to stuff all transports into a >>TCP-friendly >> > corset, which may not applicable at all. >> > >> > >> > The goal of our drafts (accurate-ecn and conex-tcp-mods) is to address t= he >> > critical part, where the transport receiver gives the *appropriate* (not >>some >> > estimated) congestion information back to the transport sender. With TCP= , >> > we are unfortunately very constrained due to the very widespread use (an= d >> > also because TCP processing is poured into hardware these days), which >> > severly limits what can be done in a backwards-compatible way. >> > >> > Best regards, >> > >> > Richard Scheffenegger >> > >> > NetApp >> > rs@netapp.com >> > +43 1 3676811 3146 Office (2143 3146 - internal) >> > +43 676 654 3146 Mobile >> > www.netapp.com >> > >> > EURO PLAZA >> > Geb=E4ude G, Stiege 7, 3.OG >> > Am Euro Platz 2 >> > A-1120 Wien >> > >> > >> > >> > > -----Original Message----- >> > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> > > Sent: Donnerstag, 07. Juli 2011 12:51 >> > > To: 'Bob Briscoe' >> > > Cc: conex@ietf.org >> > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >> > > >> > > Hi Bob, >> > > >> > > >> > > Please see in line! >> > > >> > > >> > > > -----Original Message----- >> > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] >> > > > Sent: donderdag 7 juli 2011 11:28 >> > > > To: Georgios Karagiannis >> > > > Cc: conex@ietf.org >> > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx >> > > > >> > > > Georgios, >> > > > >> > > > >On 7/7/2011, "Georgios Karagiannis" wrote: >> > > > > >Regarding the beyond reasoning statement, it is better to not >> > > discuss >> > > > > >it via email, but face to face. Will you be in Quebec during the >> > > next >> > > > > >IETF meeting? >> > > > >> > > > I meant that your response was not engaging in the reasoning put to >> > > you. >> > > > >> > > > You can go back and respond to the reasoning already given. But I >> > > don't >> > > need >> > > > to say any more. >> > > > >> > > > My main point was that the whole idea of your draft goes round in a >> > > loop >> > > > that achieves nothing. >> > > > You avoided this critical point and jumped to a detail (a detail >> > > within >> > > that loop >> > > > that already achieves nothing). >> > > >> > > Georgios: I am not sure if this loop applies to what is written in my >> > > draft. >> > > >> > > > >> > > > Now you are saying you meant something very different to what you >> > > > had written (you now say the draft was about DCCP, but the title of >> > > > your >> > > draft >> > > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP takes >> > > you >> > > off- >> > > > charter instead (see below). >> > > >> > > In the drafts I had not yet specified which transport protocol should >> > > be used, what I have specified was that the congestion exposure can be >> > > calculated using the TCP throughput formula used in TFRC (RFC5348). >> > > And according to [RFC5348] "TFRC is a congestion control mechanism >> > > designed for unicast flows operating in >> > > an Internet environment and competing with TCP traffic [FHPW00]. >> > > Instead of specifying a complete protocol, this document simply >> > > specifies a congestion control mechanism that could be used in a >> > > transport protocol such as DCCP (Datagram Congestion Control >> > > Protocol) [RFC4340], in an application incorporating end-to-end >> > > congestion control at the application level, or in the context of >> > > endpoint congestion management [BRS99].", from [RFC5348]. >> > > >> > > So I do not think that I was saying something in the previous email >> > > that is different than what is stated in my draft. >> > > >> > > >> > > > >> > > > At 07:08 07/07/2011, Georgios Karagiannis wrote: >> > > > >Do you mean that is off-charter because is using for feedback DCCP >> > > > >& TFRC (RFC5348, RFC5622, RFC4342) instead of TCP? >> > > > >> > > > Yes. >> > > > >> > > > ConEx is primarily at the IP layer, but some transports need >> > > > optional >> > > changes >> > > > to their feedback. The charter says we will focus on TCP first. >> > > >> > > Georgios: In the charter the following is mentioned: >> > > "Today, the network may signal >> > > congestion by ECN markings or by dropping packets, and the receiver >> > > passes this information back to the sender in transport-layer >> > > acknowledgements. The mechanism to be developed by the CONEX WG >> > will >> > > enable the sender to also relay the congestion information back into >> > > the network in-band at the IP layer, such that the total level of >> > > congestion is visible to all IP devices along the path, from where it >> > > could, for example, be provided as input to traffic management." , >> > > from [Conex charter] >> > > >> > > >> > > Further down the charter mentions: >> > > >> > > "Primary work items are: >> > > >> > > * An Informational document containing an abstract description of the >> > > congestion exposure mechanism that is independent of specific >> > > transport protocols and congestion information encoding techniques >> > > needed for different IP protocol versions. >> > > >> > > * An Experimental specification of an IPv6 packet structure that >> > > encapsulates CONEX information, defining a packet format and an >> > > interpretation. >> > > >> > > >> > > * An Experimental specification of a modification to TCP, for the >> > > timely transport of congestion information from the destination to the >> > > sender.", from [Conex charter] >> > > >> > > >> > > By reading the first paragraph from above, I can understand that >> > > Conex WG will use transport-layer acknowledgement to pass the >> > > congestion information (signalled by ECN markings or by dropping >> > > packets to the receiver) from the receiver to the sender. >> > > Thus any types of transport protocols can be used for this purpose >> > > (e.g., TCP, DCCP). >> > > >> > > >> > > By reading the third bullet from above, I can understand that the >> > > CONEX WG will primarily focus on TCP. >> > > >> > > However, to my understanding this does not imply that other types of >> > > transport protocols, e.g. ., DCCP, are off-charter. This is in my >> > > opinion not explicitly mentioned in the charter. >> > > >> > > Could the WG chairs comment on this issues, see below: >> > > >> > > Conex needs transport protocols to carry congestion information from a >> > > receiver to a sender. >> > > Are transport protocols such as DCCP out of the Conex charter scope? >> > > >> > > > >> > > > You are criticising a draft written to satisfy this charter >> > > objective. You >> > > are >> > > > saying it is difficult to change the semantics of TCP header fields >> > > (which >> > > we >> > > > are already chartered to do). So you propose everyone should have to >> > > use >> > > > DCCP in order to use ConEx. That would require every application in >> > > the >> > > > world that uses TCP to be changed to call DCCP instead, in order to >> > > use >> > > > ConEx. And most middleboxes (NATs, firewalls) would have to be >> > > changed >> > > > too. >> > > >> > > Georgios: Sorry Bob, but this is your interpretation. >> > > >> > > Another interpretation could be: >> > > It is good to provide the means such that Conex is used in combination >> > > with applications that are using not only TCP as a transport protocol, >> > > but also the ones that are using DCCP as transport protocol. >> > > Furthermore, start with a solution to calculate congestion, in this >> > > case the TFRC [RF5348], that is simple and does not imply many >> > > standardization changes on the transport protocols using this >> > > solution. >> > > Moreover, note that I am in favour that a TCP based transport solution >> > > should be specified in parallel. >> > > >> > > Best regards, >> > > Georgios >> > > >> > > >> > > _______________________________________________ >> > > conex mailing list >> > > conex@ietf.org >> > > https://www.ietf.org/mailman/listinfo/conex > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design=20 From karagian@cs.utwente.nl Fri Jul 8 13:00:29 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 1F3F021F8C2E for ; Fri, 8 Jul 2011 13:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 fR6Nym8of8L1 for ; Fri, 8 Jul 2011 13:00:28 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 690AF21F8C1C for ; Fri, 8 Jul 2011 13:00:28 -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 p68Jwmb3016731 for ; Fri, 8 Jul 2011 21:58:49 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 08 Jul 2011 20:00:32 +0000 To: conex@ietf.org Date: Fri, 08 Jul 2011 20:00:32 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: 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, 08 Jul 2011 21:58:58 +0200 (MEST) Subject: [conex] new draft: Non-TCP based Feedback for Congestion Exposure 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, 08 Jul 2011 20:00:29 -0000 Hi all, A new version of I-D, draft-karagiannis-conex-congestion-calculation-01.txt has been just submitted by Georgios Karagiannis and posted to the IETF repository, see: http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation-01.txt The title of this I-D is: "Non-TCP based Feedback for Congestion Exposure" This document describes a solution used to feedback congestion information calculated at the receiver, back to the sender using non-TCP based protocols. The main advantage of this approach is that applications that are not using the TCP protocol as transport protocol could also apply the Conex concept to rely congestion experienced on the end-to-end path back into the network. Best regards, Georgios From karagian@cs.utwente.nl Fri Jul 8 15:08: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 15F789E800C for ; Fri, 8 Jul 2011 15:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 UgCe0wMHTqaY for ; Fri, 8 Jul 2011 15:08:33 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 62F289E800B for ; Fri, 8 Jul 2011 15:08:33 -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 p68M6rmQ000433 for ; Sat, 9 Jul 2011 00:06:53 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 08 Jul 2011 22:08:37 +0000 To: "conex@ietf.org" Date: Fri, 08 Jul 2011 22:08:36 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <20110708212710.32030.5607.idtracker@ietfa.amsl.com> 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]); Sat, 09 Jul 2011 00:07:01 +0200 (MEST) Subject: [conex] new draft: Exposing Conex Throughput using non-TCP Feedback 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, 08 Jul 2011 22:08:34 -0000 Hi all A new version of I-D, draft-karagiannis-conex-throughput-exposure-02.txt has been successfully submitted, see below: http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-02.txt The title of this draft is: Exposing Conex Throughput using non-TCP Feedback This draft is focusing on relaying throughput instead of congestion back into the network in-band at the IP layer, such that the total level of throughput is visible to all IP devices along the path. The advantage of this approach is that applications that are not using the TCP protocol as transport protocol could also apply the Conex concept to rely the throughput experienced on the end-to-end path back into the network. Best regards, Georgios From karagian@cs.utwente.nl Fri Jul 8 23:18: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 D6E5C21F858E for ; Fri, 8 Jul 2011 23:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_62=0.6] 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 hB-Xfi5L8-qV for ; Fri, 8 Jul 2011 23:18:19 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id E35E921F856B for ; Fri, 8 Jul 2011 23:18:18 -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 p696Gb0v021319; Sat, 9 Jul 2011 08:16:37 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 09 Jul 2011 06:18:19 +0000 To: "Bob Briscoe" Date: Sat, 09 Jul 2011 06:18:19 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107071925.p67JPZY0027277@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]); Sat, 09 Jul 2011 08:16:49 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] Non-goals and/or misconceptions for 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, 09 Jul 2011 06:18:19 -0000 Hi Bob, The text looks good, but I have one comment associated with the following paragraph: > Capacity provisioning in relation to ConEx is another area of > confusion. Congestion-based traffic management is not an alternative > to good capacity provisioning. Either or both can be good practice > depending on the situation, and ConEx can provide a useful metric for > both (see Section 5.4). Will the features provided Connex apply only to applications that are using TCP as a transport protocol? In other words, will the Conex useful metric, mentioned in the paragraph above, be used by capacity provisioning and congestion-based traffic management only for applcations that are using TCP as transport protocol (and not for applications that are using a non-TCP transport protocol)? If the answer is yes, then please see below: Consider now that there are applications that use a non-TCP protocol, e.g., DCCP, that are generating a lot of traffic and are the main causes of congestion in the network. Since the capacity provisioning and congestion-based traffic management will not be able to use the Conex metrics, then the behaviour of the non-TCP applications that are generating the congestion cannot be effectively "controled" by using the augmented features provided by Conex. In this case for these non-TCP based applications only the current means of providing congestion control and capacity provisioning can be used. It might also mean that only the applications that are using TCP as transport protocol will be effectively "controlled", while they should'nt. Best regards, Georgios On 7/7/2011, "Bob Briscoe" wrote: >Phil & all, > >I've decided the question & answer style broke up the flow. So here >it is re-written in prose and much shorter cos I've cut out chunks >that weren't really nec (e.g. utilisation !=3D congestion)... > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >2.2. Non-Goals of ConEx and Common Misconceptions > > Congestion exposure is about the transport sender exposing congestion > to the network, not the other way round. That would not make sense > given by design the transport endpoints handle congestion in the > TCP/IP protocol suite. > > Nonetheless, it is a non-goal for IP layer devices to use this ConEx > information to do fine-grained congestion control. That is still > best done at the transport sender. There is also no expectation that > the information will be used by every IP router and forwarding > device. More likely, specific ConEx-based functions like traffic > management will be added to edge routers. This in turn should > incentivize end-system transports to be more careful about congesting > others. > > Note that good behaviour at individual flow granularity is the > intended outcome, not the forcing function--it is the end, not the > means. Enforcing per-flow compliance to the TCP congestion response > (or any per-flow rate enforcement) is a non-goal: > > o It used to be commonly believed that TCP-friendliness was critical > to fairness on the Internet. However, a particular congestion > control algorithm doesn't determine how much data an application > transfers, or how many flows it opens, or which congestion control > algorithm an application uses, or how many applications the user > runs, or how many users are active at once. These factors all > have a stronger impact on how great a share of a link is available > for any particular data transfer. To achieve fairness at this > broader granularity (between users, homes, sites or whole > networks) requires that individual flows in the same bottleneck > will sometimes be very unequal. > > o If the network forced everything to be TCP-friendly, some > important applications would not work. Worse still, this would > prevent deployment of higher performance replacements to TCP. It > is important to allow give and take between one user's flows: some > > > >Briscoe & Woundy Expires January 5, 2012 [Page 7] > >Internet-Draft ConEx Mechanism July 2011 > > > can be more aggressive than TCP and others less, e.g. long > transfers, following the example of LEDBAT [LEDBAT] (see > Section 5.2). > > Therefore, network enforcement of per-flow fairness is not only a > non-goal, it would be a harmful goal in many respects. > > Capacity provisioning in relation to ConEx is another area of > confusion. Congestion-based traffic management is not an alternative > to good capacity provisioning. Either or both can be good practice > depending on the situation, and ConEx can provide a useful metric for > both (see Section 5.4). > > However, removing congestion from _all_ parts of a network is > unlikely to be a goal. If an end-to-end transport protocol cannot go > fast enough to cause congestion somewhere along the path, it is > probably broken. A good transport protocol will continue to > accelerate until it encounters a bottleneck--typically in an access > network (or all too often in the receiver's buffer, but that's > another story). Low levels of congestion _somewhere_ are therefore > healthy. Just to be clear though, zero congestion somewhere (e.g. the > core) is also perfectly healthy. >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > >At 13:34 07/07/2011, philip.eardley@bt.com wrote: >>Your suggestions look good. >>Personally would put them later. A good, simple explanation of what >>conex is about should reduce the chances of a reader being >>misconceived. You could always put an advert early in the doc >> >>Cong & utilisation - would make this a question in its own right. >>I'd expand it a bit. Explain how acting assuming it's one (& in fact >>it's the other) leads to wrong 'cures'. >> >>Network traffic mgt does congestion control? - the bullet could be >>clearer. TM can be on just as fast timescales as cong control. the >>"arbitrate overall fairness" point is only one possibility for how >>TM can use conex info (& the next bullet explains that case) >> >>I'm not sure the first question is quite right, but am not inspired >>with an alternative at the moment >> >> >>-----Original Message----- > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From philip.eardley@bt.com Sat Jul 9 08:14:37 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 9728321F8799 for ; Sat, 9 Jul 2011 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eul+PwJjJU6x for ; Sat, 9 Jul 2011 08:14:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D421F876C for ; Sat, 9 Jul 2011 08:14:36 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sat, 9 Jul 2011 16:14:34 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Sat, 9 Jul 2011 16:14:35 +0100 From: To: , Date: Sat, 9 Jul 2011 16:14:34 +0100 Thread-Topic: [conex] Non-goals and/or misconceptions for conex-concepts-uses Thread-Index: Acw+AAHePXEQPRzYRFmsnTLHM7PZqAASi2vh Message-ID: <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> References: <201107071925.p67JPZY0027277@bagheera.jungle.bt.co.uk>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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, 09 Jul 2011 15:14:37 -0000 Conex enables IP nodes to see information about the whole path congestion, = so that it is visible as a useful metric; for example to inform the operato= r's traffic management. In order to achieve this, the sender signals the information at the transpo= rt layer. The WG is chartered to define this signalling for the TCP transport. It wou= ld clearly be possible to also define this signalling for non-TCP transport= s phil ________________________________________ From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of Georgios= Karagiannis [karagian@cs.utwente.nl] Sent: 09 July 2011 07:18 To: Briscoe,RJ,Bob,DES8 R Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-use= s Hi Bob, The text looks good, but I have one comment associated with the following paragraph: > Capacity provisioning in relation to ConEx is another area of > confusion. Congestion-based traffic management is not an alternative > to good capacity provisioning. Either or both can be good practice > depending on the situation, and ConEx can provide a useful metric for > both (see Section 5.4). Will the features provided Connex apply only to applications that are using TCP as a transport protocol? In other words, will the Conex useful metric, mentioned in the paragraph above, be used by capacity provisioning and congestion-based traffic management only for applcations that are using TCP as transport protocol (and not for applications that are using a non-TCP transport protocol)? If the answer is yes, then please see below: Consider now that there are applications that use a non-TCP protocol, e.g., DCCP, that are generating a lot of traffic and are the main causes of congestion in the network. Since the capacity provisioning and congestion-based traffic management will not be able to use the Conex metrics, then the behaviour of the non-TCP applications that are generating the congestion cannot be effectively "controled" by using the augmented features provided by Conex. In this case for these non-TCP based applications only the current means of providing congestion control and capacity provisioning can be used. It might also mean that only the applications that are using TCP as transport protocol will be effectively "controlled", while they should'nt. Best regards, Georgios On 7/7/2011, "Bob Briscoe" wrote: >Phil & all, > >I've decided the question & answer style broke up the flow. So here >it is re-written in prose and much shorter cos I've cut out chunks >that weren't really nec (e.g. utilisation !=3D congestion)... > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >2.2. Non-Goals of ConEx and Common Misconceptions > > Congestion exposure is about the transport sender exposing congestion > to the network, not the other way round. That would not make sense > given by design the transport endpoints handle congestion in the > TCP/IP protocol suite. > > Nonetheless, it is a non-goal for IP layer devices to use this ConEx > information to do fine-grained congestion control. That is still > best done at the transport sender. There is also no expectation that > the information will be used by every IP router and forwarding > device. More likely, specific ConEx-based functions like traffic > management will be added to edge routers. This in turn should > incentivize end-system transports to be more careful about congesting > others. > > Note that good behaviour at individual flow granularity is the > intended outcome, not the forcing function--it is the end, not the > means. Enforcing per-flow compliance to the TCP congestion response > (or any per-flow rate enforcement) is a non-goal: > > o It used to be commonly believed that TCP-friendliness was critical > to fairness on the Internet. However, a particular congestion > control algorithm doesn't determine how much data an application > transfers, or how many flows it opens, or which congestion control > algorithm an application uses, or how many applications the user > runs, or how many users are active at once. These factors all > have a stronger impact on how great a share of a link is available > for any particular data transfer. To achieve fairness at this > broader granularity (between users, homes, sites or whole > networks) requires that individual flows in the same bottleneck > will sometimes be very unequal. > > o If the network forced everything to be TCP-friendly, some > important applications would not work. Worse still, this would > prevent deployment of higher performance replacements to TCP. It > is important to allow give and take between one user's flows: some > > > >Briscoe & Woundy Expires January 5, 2012 [Page 7] > >Internet-Draft ConEx Mechanism July 2011 > > > can be more aggressive than TCP and others less, e.g. long > transfers, following the example of LEDBAT [LEDBAT] (see > Section 5.2). > > Therefore, network enforcement of per-flow fairness is not only a > non-goal, it would be a harmful goal in many respects. > > Capacity provisioning in relation to ConEx is another area of > confusion. Congestion-based traffic management is not an alternative > to good capacity provisioning. Either or both can be good practice > depending on the situation, and ConEx can provide a useful metric for > both (see Section 5.4). > > However, removing congestion from _all_ parts of a network is > unlikely to be a goal. If an end-to-end transport protocol cannot go > fast enough to cause congestion somewhere along the path, it is > probably broken. A good transport protocol will continue to > accelerate until it encounters a bottleneck--typically in an access > network (or all too often in the receiver's buffer, but that's > another story). Low levels of congestion _somewhere_ are therefore > healthy. Just to be clear though, zero congestion somewhere (e.g. the > core) is also perfectly healthy. >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > >At 13:34 07/07/2011, philip.eardley@bt.com wrote: >>Your suggestions look good. >>Personally would put them later. A good, simple explanation of what >>conex is about should reduce the chances of a reader being >>misconceived. You could always put an advert early in the doc >> >>Cong & utilisation - would make this a question in its own right. >>I'd expand it a bit. Explain how acting assuming it's one (& in fact >>it's the other) leads to wrong 'cures'. >> >>Network traffic mgt does congestion control? - the bullet could be >>clearer. TM can be on just as fast timescales as cong control. the >>"arbitrate overall fairness" point is only one possibility for how >>TM can use conex info (& the next bullet explains that case) >> >>I'm not sure the first question is quite right, but am not inspired >>with an alternative at the moment >> >> >>-----Original Message----- > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >_______________________________________________ >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 rs@netapp.com Sat Jul 9 13:38: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 9C79321F8A14 for ; Sat, 9 Jul 2011 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.969 X-Spam-Level: X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6, 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 jPyQCX2S3psU for ; Sat, 9 Jul 2011 13:38:33 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1080621F89D4 for ; Sat, 9 Jul 2011 13:38:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,505,1304319600"; d="scan'208";a="253710129" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 09 Jul 2011 13:38:31 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p69KcVE6014286; Sat, 9 Jul 2011 13:38:31 -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); Sat, 9 Jul 2011 21:38:31 +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: Sat, 9 Jul 2011 21:38:06 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F2A221F@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Non-goals and/or misconceptions for conex-concepts-uses Thread-Index: Acw+AAHePXEQPRzYRFmsnTLHM7PZqAASi2vhAAs2mnA= References: <201107071925.p67JPZY0027277@bagheera.jungle.bt.co.uk>, <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> From: "Scheffenegger, Richard" To: , , X-OriginalArrivalTime: 09 Jul 2011 20:38:31.0455 (UTC) FILETIME=[2A5BAAF0:01CC3E78] Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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, 09 Jul 2011 20:38:34 -0000 Perhaps a survey of more commonly used transports should be made, with a investigation if the transport receivers provide "good enough" or accurate ECN / congestion feedback to the sender... I.e. DCCP has already more than adequate receiver->sender feedback (the exact CE "bitstream" can be reconstructed on the sender side, even at a very low acknowledgement ratio). I'm not really familiar with other commonly used transports (SCTP, RTP, Reliable Multicast,...) to know what their feedback mechanism for ECN/congestion looks like. (I believe RTP recently had the necessary extensions added, to support ECN more than adequate). Even if that is strictly speaking out of scope, it may reveal how these transports fit in with Conex. Regards, Richard Scheffenegger > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Samstag, 09. Juli 2011 17:15 > To: karagian@cs.utwente.nl; bob.briscoe@bt.com > Cc: conex@ietf.org > Subject: Re: [conex] Non-goals and/or misconceptions for conex- > concepts-uses >=20 > Conex enables IP nodes to see information about the whole path > congestion, so that it is visible as a useful metric; for example to > inform the operator's traffic management. >=20 > In order to achieve this, the sender signals the information at the > transport layer. > The WG is chartered to define this signalling for the TCP transport. It > would clearly be possible to also define this signalling for non-TCP > transports >=20 > phil >=20 > ________________________________________ > From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of > Georgios Karagiannis [karagian@cs.utwente.nl] > Sent: 09 July 2011 07:18 > To: Briscoe,RJ,Bob,DES8 R > Cc: conex@ietf.org > Subject: Re: [conex] Non-goals and/or misconceptions for conex- > concepts-uses >=20 > Hi Bob, >=20 > The text looks good, but I have one comment associated with the > following > paragraph: >=20 > > Capacity provisioning in relation to ConEx is another area of > > confusion. Congestion-based traffic management is not an > alternative > > to good capacity provisioning. Either or both can be good practice > > depending on the situation, and ConEx can provide a useful metric > for > > both (see Section 5.4). >=20 >=20 > Will the features provided Connex apply only to applications that are > using TCP as a transport protocol? > In other words, will the Conex useful metric, mentioned in the > paragraph > above, be used by capacity provisioning and congestion-based traffic > management only for applcations that are using TCP as transport > protocol > (and not for applications that are using a non-TCP transport protocol)? >=20 > If the answer is yes, then please see below: >=20 >=20 > Consider now that there are applications that use a non-TCP protocol, > e.g., DCCP, that are generating a lot of traffic and are the main > causes > of congestion in the network. >=20 > Since the capacity provisioning and congestion-based traffic management > will not be able to use the Conex metrics, then the behaviour of the > non-TCP applications that are generating the congestion cannot be > effectively "controled" by using the augmented features provided by > Conex. > In this case for these non-TCP based applications only the current > means > of providing congestion control and capacity provisioning can be used. >=20 > It might also mean that only the applications that are using TCP as > transport protocol will be effectively "controlled", while they > should'nt. >=20 > Best regards, > Georgios >=20 >=20 >=20 > On 7/7/2011, "Bob Briscoe" wrote: >=20 > >Phil & all, > > > >I've decided the question & answer style broke up the flow. So here > >it is re-written in prose and much shorter cos I've cut out chunks > >that weren't really nec (e.g. utilisation !=3D congestion)... > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >2.2. Non-Goals of ConEx and Common Misconceptions > > > > Congestion exposure is about the transport sender exposing > congestion > > to the network, not the other way round. That would not make > sense > > given by design the transport endpoints handle congestion in the > > TCP/IP protocol suite. > > > > Nonetheless, it is a non-goal for IP layer devices to use this > ConEx > > information to do fine-grained congestion control. That is still > > best done at the transport sender. There is also no expectation > that > > the information will be used by every IP router and forwarding > > device. More likely, specific ConEx-based functions like traffic > > management will be added to edge routers. This in turn should > > incentivize end-system transports to be more careful about > congesting > > others. > > > > Note that good behaviour at individual flow granularity is the > > intended outcome, not the forcing function--it is the end, not the > > means. Enforcing per-flow compliance to the TCP congestion > response > > (or any per-flow rate enforcement) is a non-goal: > > > > o It used to be commonly believed that TCP-friendliness was > critical > > to fairness on the Internet. However, a particular congestion > > control algorithm doesn't determine how much data an > application > > transfers, or how many flows it opens, or which congestion > control > > algorithm an application uses, or how many applications the > user > > runs, or how many users are active at once. These factors all > > have a stronger impact on how great a share of a link is > available > > for any particular data transfer. To achieve fairness at this > > broader granularity (between users, homes, sites or whole > > networks) requires that individual flows in the same bottleneck > > will sometimes be very unequal. > > > > o If the network forced everything to be TCP-friendly, some > > important applications would not work. Worse still, this would > > prevent deployment of higher performance replacements to TCP. > It > > is important to allow give and take between one user's flows: > some > > > > > > > >Briscoe & Woundy Expires January 5, 2012 [Page > 7] > > > >Internet-Draft ConEx Mechanism July > 2011 > > > > > > can be more aggressive than TCP and others less, e.g. long > > transfers, following the example of LEDBAT [LEDBAT] (see > > Section 5.2). > > > > Therefore, network enforcement of per-flow fairness is not only a > > non-goal, it would be a harmful goal in many respects. > > > > Capacity provisioning in relation to ConEx is another area of > > confusion. Congestion-based traffic management is not an > alternative > > to good capacity provisioning. Either or both can be good > practice > > depending on the situation, and ConEx can provide a useful metric > for > > both (see Section 5.4). > > > > However, removing congestion from _all_ parts of a network is > > unlikely to be a goal. If an end-to-end transport protocol cannot > go > > fast enough to cause congestion somewhere along the path, it is > > probably broken. A good transport protocol will continue to > > accelerate until it encounters a bottleneck--typically in an > access > > network (or all too often in the receiver's buffer, but that's > > another story). Low levels of congestion _somewhere_ are > therefore > > healthy. Just to be clear though, zero congestion somewhere (e.g. > the > > core) is also perfectly healthy. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > > > > >At 13:34 07/07/2011, philip.eardley@bt.com wrote: > >>Your suggestions look good. > >>Personally would put them later. A good, simple explanation of what > >>conex is about should reduce the chances of a reader being > >>misconceived. You could always put an advert early in the doc > >> > >>Cong & utilisation - would make this a question in its own right. > >>I'd expand it a bit. Explain how acting assuming it's one (& in fact > >>it's the other) leads to wrong 'cures'. > >> > >>Network traffic mgt does congestion control? - the bullet could be > >>clearer. TM can be on just as fast timescales as cong control. the > >>"arbitrate overall fairness" point is only one possibility for how > >>TM can use conex info (& the next bullet explains that case) > >> > >>I'm not sure the first question is quite right, but am not inspired > >>with an alternative at the moment > >> > >> > >>-----Original Message----- > > > >________________________________________________________________ > >Bob Briscoe, BT Innovate & Design > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Sat Jul 9 13:44: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 F0D6421F8A17 for ; Sat, 9 Jul 2011 13:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.088 X-Spam-Level: * X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6, 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 4AGt7f+WoQVV for ; Sat, 9 Jul 2011 13:44:06 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id ED40421F89EB for ; Sat, 9 Jul 2011 13:44:05 -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 p69KgP8b029804; Sat, 9 Jul 2011 22:42:25 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 09 Jul 2011 20:44:09 +0000 To: "philip.eardley@bt.com" , "bob.briscoe@bt.com" Date: Sat, 09 Jul 2011 20:44:09 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <9lmt7nrQ.1310244249.1181130.karagian@ewi.utwente.nl> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> 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]); Sat, 09 Jul 2011 22:42:36 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] Non-goals and/or misconceptions for 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, 09 Jul 2011 20:44:07 -0000 Hi Phil, Thanks, please see in line! On 7/9/2011, "philip.eardley@bt.com" wrote: >Conex enables IP nodes to see information about the whole path congestion, s= o that it is visible as a useful metric; for example to inform the operator's= traffic management. > >In order to achieve this, the sender signals the information at the transpor= t layer. Georgios: Okay, but in my opinin this should be done for TCP and non-TCP based applications, see my previous email. >The WG is chartered to define this signalling for the TCP transport. It woul= d clearly be possible to also define this signalling for non-TCP transports Georgios: Okay, but does this mean that Conex rechartering is needed in order to achieve this? Best regards, Goergios > >phil > >________________________________________ >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of Georgios = Karagiannis [karagian@cs.utwente.nl] >Sent: 09 July 2011 07:18 >To: Briscoe,RJ,Bob,DES8 R >Cc: conex@ietf.org >Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-uses > >Hi Bob, > >The text looks good, but I have one comment associated with the following >paragraph: > > > Capacity provisioning in relation to ConEx is another area of > > confusion. Congestion-based traffic management is not an alternative > > to good capacity provisioning. Either or both can be good practice > > depending on the situation, and ConEx can provide a useful metric for > > both (see Section 5.4). > > >Will the features provided Connex apply only to applications that are >using TCP as a transport protocol? >In other words, will the Conex useful metric, mentioned in the paragraph >above, be used by capacity provisioning and congestion-based traffic >management only for applcations that are using TCP as transport protocol >(and not for applications that are using a non-TCP transport protocol)? > >If the answer is yes, then please see below: > > >Consider now that there are applications that use a non-TCP protocol, >e.g., DCCP, that are generating a lot of traffic and are the main causes >of congestion in the network. > >Since the capacity provisioning and congestion-based traffic management >will not be able to use the Conex metrics, then the behaviour of the >non-TCP applications that are generating the congestion cannot be >effectively "controled" by using the augmented features provided by >Conex. >In this case for these non-TCP based applications only the current means >of providing congestion control and capacity provisioning can be used. > >It might also mean that only the applications that are using TCP as >transport protocol will be effectively "controlled", while they >should'nt. > >Best regards, >Georgios > > > >On 7/7/2011, "Bob Briscoe" wrote: > >>Phil & all, >> >>I've decided the question & answer style broke up the flow. So here >>it is re-written in prose and much shorter cos I've cut out chunks >>that weren't really nec (e.g. utilisation !=3D congestion)... >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>2.2. Non-Goals of ConEx and Common Misconceptions >> >> Congestion exposure is about the transport sender exposing congestion >> to the network, not the other way round. That would not make sense >> given by design the transport endpoints handle congestion in the >> TCP/IP protocol suite. >> >> Nonetheless, it is a non-goal for IP layer devices to use this ConEx >> information to do fine-grained congestion control. That is still >> best done at the transport sender. There is also no expectation that >> the information will be used by every IP router and forwarding >> device. More likely, specific ConEx-based functions like traffic >> management will be added to edge routers. This in turn should >> incentivize end-system transports to be more careful about congesting >> others. >> >> Note that good behaviour at individual flow granularity is the >> intended outcome, not the forcing function--it is the end, not the >> means. Enforcing per-flow compliance to the TCP congestion response >> (or any per-flow rate enforcement) is a non-goal: >> >> o It used to be commonly believed that TCP-friendliness was critical >> to fairness on the Internet. However, a particular congestion >> control algorithm doesn't determine how much data an application >> transfers, or how many flows it opens, or which congestion control >> algorithm an application uses, or how many applications the user >> runs, or how many users are active at once. These factors all >> have a stronger impact on how great a share of a link is available >> for any particular data transfer. To achieve fairness at this >> broader granularity (between users, homes, sites or whole >> networks) requires that individual flows in the same bottleneck >> will sometimes be very unequal. >> >> o If the network forced everything to be TCP-friendly, some >> important applications would not work. Worse still, this would >> prevent deployment of higher performance replacements to TCP. It >> is important to allow give and take between one user's flows: some >> >> >> >>Briscoe & Woundy Expires January 5, 2012 [Page 7] >> >>Internet-Draft ConEx Mechanism July 2011 >> >> >> can be more aggressive than TCP and others less, e.g. long >> transfers, following the example of LEDBAT [LEDBAT] (see >> Section 5.2). >> >> Therefore, network enforcement of per-flow fairness is not only a >> non-goal, it would be a harmful goal in many respects. >> >> Capacity provisioning in relation to ConEx is another area of >> confusion. Congestion-based traffic management is not an alternative >> to good capacity provisioning. Either or both can be good practice >> depending on the situation, and ConEx can provide a useful metric for >> both (see Section 5.4). >> >> However, removing congestion from _all_ parts of a network is >> unlikely to be a goal. If an end-to-end transport protocol cannot go >> fast enough to cause congestion somewhere along the path, it is >> probably broken. A good transport protocol will continue to >> accelerate until it encounters a bottleneck--typically in an access >> network (or all too often in the receiver's buffer, but that's >> another story). Low levels of congestion _somewhere_ are therefore >> healthy. Just to be clear though, zero congestion somewhere (e.g. the >> core) is also perfectly healthy. >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >> >> >>At 13:34 07/07/2011, philip.eardley@bt.com wrote: >>>Your suggestions look good. >>>Personally would put them later. A good, simple explanation of what >>>conex is about should reduce the chances of a reader being >>>misconceived. You could always put an advert early in the doc >>> >>>Cong & utilisation - would make this a question in its own right. >>>I'd expand it a bit. Explain how acting assuming it's one (& in fact >>>it's the other) leads to wrong 'cures'. >>> >>>Network traffic mgt does congestion control? - the bullet could be >>>clearer. TM can be on just as fast timescales as cong control. the >>>"arbitrate overall fairness" point is only one possibility for how >>>TM can use conex info (& the next bullet explains that case) >>> >>>I'm not sure the first question is quite right, but am not inspired >>>with an alternative at the moment >>> >>> >>>-----Original Message----- >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >> >>_______________________________________________ >>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 karagian@cs.utwente.nl Sat Jul 9 13:49:07 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 4129521F8A70 for ; Sat, 9 Jul 2011 13:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6] 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 x3Qj-ihhv2tl for ; Sat, 9 Jul 2011 13:49:06 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C51321F8A6F for ; Sat, 9 Jul 2011 13:49:05 -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 p69KlRS0000370; Sat, 9 Jul 2011 22:47:27 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 09 Jul 2011 20:49:11 +0000 To: "Scheffenegger, Richard" , "philip.eardley@bt.com" , "bob.briscoe@bt.com" Date: Sat, 09 Jul 2011 20:49:10 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <5FDC413D5FA246468C200652D63E627A0F2A221F@LDCMVEXC1-PRD.hq.netapp.com> 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]); Sat, 09 Jul 2011 22:47:36 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] Non-goals and/or misconceptions for 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, 09 Jul 2011 20:49:07 -0000 Hi Richard, This is a very good suggestion! If appreciate I could work on such an activity! Best regards, Georgios On 7/9/2011, "Scheffenegger, Richard" wrote: > >Perhaps a survey of more commonly used transports should be made, with a >investigation if the transport receivers provide "good enough" or >accurate ECN / congestion feedback to the sender... > >I.e. DCCP has already more than adequate receiver->sender feedback (the >exact CE "bitstream" can be reconstructed on the sender side, even at a >very low acknowledgement ratio). I'm not really familiar with other >commonly used transports (SCTP, RTP, Reliable Multicast,...) to know >what their feedback mechanism for ECN/congestion looks like. (I believe >RTP recently had the necessary extensions added, to support ECN more >than adequate). > >Even if that is strictly speaking out of scope, it may reveal how these >transports fit in with Conex. > >Regards, > >Richard Scheffenegger > > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Samstag, 09. Juli 2011 17:15 >> To: karagian@cs.utwente.nl; bob.briscoe@bt.com >> Cc: conex@ietf.org >> Subject: Re: [conex] Non-goals and/or misconceptions for conex- >> concepts-uses >>=20 >> Conex enables IP nodes to see information about the whole path >> congestion, so that it is visible as a useful metric; for example to >> inform the operator's traffic management. >>=20 >> In order to achieve this, the sender signals the information at the >> transport layer. >> The WG is chartered to define this signalling for the TCP transport. >It >> would clearly be possible to also define this signalling for non-TCP >> transports >>=20 >> phil >>=20 >> ________________________________________ >> From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of >> Georgios Karagiannis [karagian@cs.utwente.nl] >> Sent: 09 July 2011 07:18 >> To: Briscoe,RJ,Bob,DES8 R >> Cc: conex@ietf.org >> Subject: Re: [conex] Non-goals and/or misconceptions for conex- >> concepts-uses >>=20 >> Hi Bob, >>=20 >> The text looks good, but I have one comment associated with the >> following >> paragraph: >>=20 >> > Capacity provisioning in relation to ConEx is another area of >> > confusion. Congestion-based traffic management is not an >> alternative >> > to good capacity provisioning. Either or both can be good >practice >> > depending on the situation, and ConEx can provide a useful metric >> for >> > both (see Section 5.4). >>=20 >>=20 >> Will the features provided Connex apply only to applications that are >> using TCP as a transport protocol? >> In other words, will the Conex useful metric, mentioned in the >> paragraph >> above, be used by capacity provisioning and congestion-based traffic >> management only for applcations that are using TCP as transport >> protocol >> (and not for applications that are using a non-TCP transport >protocol)? >>=20 >> If the answer is yes, then please see below: >>=20 >>=20 >> Consider now that there are applications that use a non-TCP protocol, >> e.g., DCCP, that are generating a lot of traffic and are the main >> causes >> of congestion in the network. >>=20 >> Since the capacity provisioning and congestion-based traffic >management >> will not be able to use the Conex metrics, then the behaviour of the >> non-TCP applications that are generating the congestion cannot be >> effectively "controled" by using the augmented features provided by >> Conex. >> In this case for these non-TCP based applications only the current >> means >> of providing congestion control and capacity provisioning can be used. >>=20 >> It might also mean that only the applications that are using TCP as >> transport protocol will be effectively "controlled", while they >> should'nt. >>=20 >> Best regards, >> Georgios >>=20 >>=20 >>=20 >> On 7/7/2011, "Bob Briscoe" wrote: >>=20 >> >Phil & all, >> > >> >I've decided the question & answer style broke up the flow. So here >> >it is re-written in prose and much shorter cos I've cut out chunks >> >that weren't really nec (e.g. utilisation !=3D congestion)... >> > >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >2.2. Non-Goals of ConEx and Common Misconceptions >> > >> > Congestion exposure is about the transport sender exposing >> congestion >> > to the network, not the other way round. That would not make >> sense >> > given by design the transport endpoints handle congestion in the >> > TCP/IP protocol suite. >> > >> > Nonetheless, it is a non-goal for IP layer devices to use this >> ConEx >> > information to do fine-grained congestion control. That is still >> > best done at the transport sender. There is also no expectation >> that >> > the information will be used by every IP router and forwarding >> > device. More likely, specific ConEx-based functions like traffic >> > management will be added to edge routers. This in turn should >> > incentivize end-system transports to be more careful about >> congesting >> > others. >> > >> > Note that good behaviour at individual flow granularity is the >> > intended outcome, not the forcing function--it is the end, not >the >> > means. Enforcing per-flow compliance to the TCP congestion >> response >> > (or any per-flow rate enforcement) is a non-goal: >> > >> > o It used to be commonly believed that TCP-friendliness was >> critical >> > to fairness on the Internet. However, a particular congestion >> > control algorithm doesn't determine how much data an >> application >> > transfers, or how many flows it opens, or which congestion >> control >> > algorithm an application uses, or how many applications the >> user >> > runs, or how many users are active at once. These factors all >> > have a stronger impact on how great a share of a link is >> available >> > for any particular data transfer. To achieve fairness at this >> > broader granularity (between users, homes, sites or whole >> > networks) requires that individual flows in the same >bottleneck >> > will sometimes be very unequal. >> > >> > o If the network forced everything to be TCP-friendly, some >> > important applications would not work. Worse still, this >would >> > prevent deployment of higher performance replacements to TCP. >> It >> > is important to allow give and take between one user's flows: >> some >> > >> > >> > >> >Briscoe & Woundy Expires January 5, 2012 [Page >> 7] >> > >> >Internet-Draft ConEx Mechanism July >> 2011 >> > >> > >> > can be more aggressive than TCP and others less, e.g. long >> > transfers, following the example of LEDBAT [LEDBAT] (see >> > Section 5.2). >> > >> > Therefore, network enforcement of per-flow fairness is not only a >> > non-goal, it would be a harmful goal in many respects. >> > >> > Capacity provisioning in relation to ConEx is another area of >> > confusion. Congestion-based traffic management is not an >> alternative >> > to good capacity provisioning. Either or both can be good >> practice >> > depending on the situation, and ConEx can provide a useful metric >> for >> > both (see Section 5.4). >> > >> > However, removing congestion from _all_ parts of a network is >> > unlikely to be a goal. If an end-to-end transport protocol >cannot >> go >> > fast enough to cause congestion somewhere along the path, it is >> > probably broken. A good transport protocol will continue to >> > accelerate until it encounters a bottleneck--typically in an >> access >> > network (or all too often in the receiver's buffer, but that's >> > another story). Low levels of congestion _somewhere_ are >> therefore >> > healthy. Just to be clear though, zero congestion somewhere >(e.g. >> the >> > core) is also perfectly healthy. >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> > >> > >> > >> >At 13:34 07/07/2011, philip.eardley@bt.com wrote: >> >>Your suggestions look good. >> >>Personally would put them later. A good, simple explanation of what >> >>conex is about should reduce the chances of a reader being >> >>misconceived. You could always put an advert early in the doc >> >> >> >>Cong & utilisation - would make this a question in its own right. >> >>I'd expand it a bit. Explain how acting assuming it's one (& in fact >> >>it's the other) leads to wrong 'cures'. >> >> >> >>Network traffic mgt does congestion control? - the bullet could be >> >>clearer. TM can be on just as fast timescales as cong control. the >> >>"arbitrate overall fairness" point is only one possibility for how >> >>TM can use conex info (& the next bullet explains that case) >> >> >> >>I'm not sure the first question is quite right, but am not inspired >> >>with an alternative at the moment >> >> >> >> >> >>-----Original Message----- >> > >> >________________________________________________________________ >> >Bob Briscoe, BT Innovate & Design >> > >> >_______________________________________________ >> >conex mailing list >> >conex@ietf.org >> >https://www.ietf.org/mailman/listinfo/conex >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex From philip.eardley@bt.com Mon Jul 11 01:21: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 DAB4121F86F0 for ; Mon, 11 Jul 2011 01:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qhiUQjzF1Wz for ; Mon, 11 Jul 2011 01:21:24 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B89C021F86EE for ; Mon, 11 Jul 2011 01:21:23 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 09:21:22 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 11 Jul 2011 09:21:22 +0100 From: To: , Date: Mon, 11 Jul 2011 09:21:37 +0100 Thread-Topic: [conex] Non-goals and/or misconceptions for conex-concepts-uses Thread-Index: Acw+ePHwK8WsMjPpSYyc0Gda3gRtiwBKilHg Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D34B05@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> <9lmt7nrQ.1310244249.1181130.karagian@ewi.utwente.nl> In-Reply-To: <9lmt7nrQ.1310244249.1181130.karagian@ewi.utwente.nl> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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, 11 Jul 2011 08:21:25 -0000 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 09 July 2011 21:44 To: Eardley,PL,Philip,DES8 R; Briscoe,RJ,Bob,DES8 R Cc: conex@ietf.org Subject: RE: [conex] Non-goals and/or misconceptions for conex-concepts-use= s Hi Phil, Thanks, please see in line! On 7/9/2011, "philip.eardley@bt.com" wrote: >Conex enables IP nodes to see information about the whole path congestion,= so that it is visible as a useful metric; for example to inform the operat= or's traffic management. > >In order to achieve this, the sender signals the information at the transp= ort layer. Georgios: Okay, but in my opinin this should be done for TCP and non-TCP based applications, see my previous email. >The WG is chartered to define this signalling for the TCP transport. It wo= uld clearly be possible to also define this signalling for non-TCP transpor= ts Georgios: Okay, but does this mean that Conex rechartering is needed in order to achieve this? [phil] Yes.=20 I think the activity Richard suggests could be valuable, but it is outside = the charter as I read it. i remember there was a discussion during charteri= ng and it was decided to restrict to TCP, since this represents the bulk of= the traffic. phil Best regards, Goergios > >phil > >________________________________________ >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of Georgio= s Karagiannis [karagian@cs.utwente.nl] >Sent: 09 July 2011 07:18 >To: Briscoe,RJ,Bob,DES8 R >Cc: conex@ietf.org >Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-us= es > >Hi Bob, > >The text looks good, but I have one comment associated with the following >paragraph: > > > Capacity provisioning in relation to ConEx is another area of > > confusion. Congestion-based traffic management is not an alternative > > to good capacity provisioning. Either or both can be good practice > > depending on the situation, and ConEx can provide a useful metric for > > both (see Section 5.4). > > >Will the features provided Connex apply only to applications that are >using TCP as a transport protocol? >In other words, will the Conex useful metric, mentioned in the paragraph >above, be used by capacity provisioning and congestion-based traffic >management only for applcations that are using TCP as transport protocol >(and not for applications that are using a non-TCP transport protocol)? > >If the answer is yes, then please see below: > > >Consider now that there are applications that use a non-TCP protocol, >e.g., DCCP, that are generating a lot of traffic and are the main causes >of congestion in the network. > >Since the capacity provisioning and congestion-based traffic management >will not be able to use the Conex metrics, then the behaviour of the >non-TCP applications that are generating the congestion cannot be >effectively "controled" by using the augmented features provided by >Conex. >In this case for these non-TCP based applications only the current means >of providing congestion control and capacity provisioning can be used. > >It might also mean that only the applications that are using TCP as >transport protocol will be effectively "controlled", while they >should'nt. > >Best regards, >Georgios > > > >On 7/7/2011, "Bob Briscoe" wrote: > >>Phil & all, >> >>I've decided the question & answer style broke up the flow. So here >>it is re-written in prose and much shorter cos I've cut out chunks >>that weren't really nec (e.g. utilisation !=3D congestion)... >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >>2.2. Non-Goals of ConEx and Common Misconceptions >> >> Congestion exposure is about the transport sender exposing congestion >> to the network, not the other way round. That would not make sense >> given by design the transport endpoints handle congestion in the >> TCP/IP protocol suite. >> >> Nonetheless, it is a non-goal for IP layer devices to use this ConEx >> information to do fine-grained congestion control. That is still >> best done at the transport sender. There is also no expectation that >> the information will be used by every IP router and forwarding >> device. More likely, specific ConEx-based functions like traffic >> management will be added to edge routers. This in turn should >> incentivize end-system transports to be more careful about congesting >> others. >> >> Note that good behaviour at individual flow granularity is the >> intended outcome, not the forcing function--it is the end, not the >> means. Enforcing per-flow compliance to the TCP congestion response >> (or any per-flow rate enforcement) is a non-goal: >> >> o It used to be commonly believed that TCP-friendliness was critical >> to fairness on the Internet. However, a particular congestion >> control algorithm doesn't determine how much data an application >> transfers, or how many flows it opens, or which congestion control >> algorithm an application uses, or how many applications the user >> runs, or how many users are active at once. These factors all >> have a stronger impact on how great a share of a link is available >> for any particular data transfer. To achieve fairness at this >> broader granularity (between users, homes, sites or whole >> networks) requires that individual flows in the same bottleneck >> will sometimes be very unequal. >> >> o If the network forced everything to be TCP-friendly, some >> important applications would not work. Worse still, this would >> prevent deployment of higher performance replacements to TCP. It >> is important to allow give and take between one user's flows: some >> >> >> >>Briscoe & Woundy Expires January 5, 2012 [Page 7] >> >>Internet-Draft ConEx Mechanism July 2011 >> >> >> can be more aggressive than TCP and others less, e.g. long >> transfers, following the example of LEDBAT [LEDBAT] (see >> Section 5.2). >> >> Therefore, network enforcement of per-flow fairness is not only a >> non-goal, it would be a harmful goal in many respects. >> >> Capacity provisioning in relation to ConEx is another area of >> confusion. Congestion-based traffic management is not an alternative >> to good capacity provisioning. Either or both can be good practice >> depending on the situation, and ConEx can provide a useful metric for >> both (see Section 5.4). >> >> However, removing congestion from _all_ parts of a network is >> unlikely to be a goal. If an end-to-end transport protocol cannot go >> fast enough to cause congestion somewhere along the path, it is >> probably broken. A good transport protocol will continue to >> accelerate until it encounters a bottleneck--typically in an access >> network (or all too often in the receiver's buffer, but that's >> another story). Low levels of congestion _somewhere_ are therefore >> healthy. Just to be clear though, zero congestion somewhere (e.g. th= e >> core) is also perfectly healthy. >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >> >> >>At 13:34 07/07/2011, philip.eardley@bt.com wrote: >>>Your suggestions look good. >>>Personally would put them later. A good, simple explanation of what >>>conex is about should reduce the chances of a reader being >>>misconceived. You could always put an advert early in the doc >>> >>>Cong & utilisation - would make this a question in its own right. >>>I'd expand it a bit. Explain how acting assuming it's one (& in fact >>>it's the other) leads to wrong 'cures'. >>> >>>Network traffic mgt does congestion control? - the bullet could be >>>clearer. TM can be on just as fast timescales as cong control. the >>>"arbitrate overall fairness" point is only one possibility for how >>>TM can use conex info (& the next bullet explains that case) >>> >>>I'm not sure the first question is quite right, but am not inspired >>>with an alternative at the moment >>> >>> >>>-----Original Message----- >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Mon Jul 11 01:35: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 BE9D421F86E8 for ; Mon, 11 Jul 2011 01:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] 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 8A8xnmwgbkbo for ; Mon, 11 Jul 2011 01:35:24 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id A18DB21F8A43 for ; Mon, 11 Jul 2011 01:35:24 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MCdN8-1QoPR93txK-009Rbj; Mon, 11 Jul 2011 10:35:18 +0200 From: "Toby Moncaster" To: , , References: <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> <9lmt7nrQ.1310244249.1181130.karagian@ewi.utwente.nl> <9510D26531EF184D9017DF24659BB87F32E2D34B05@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D34B05@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 11 Jul 2011 09:35:17 +0100 Message-ID: <002a01cc3fa5$76f6eef0$64e4ccd0$@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: Acw+ePHwK8WsMjPpSYyc0Gda3gRtiwBKilHgAACF0wA= Content-Language: en-gb X-Provags-ID: V02:K0:lh31LSjAMZddUAoYS3koetQT6BPMROLIdHydmTS7uY2 +llcu5DhaHEg1FR66htfH38lHooddCzBGnTbNT1qj3fNz06ozo uWoYLKC63YrfGIH+Ja0B/YlowI6raA13dUQycnsKu6NUU4H6PO FpjCZtPaSEqyRK1OoimOjHWY0WS62q/yAgcqV9MlOnDT0OVzfS 2QSEkl1YQERAR7jPiZN+CNs/O+VlVCitqVViYr1MDY= Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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, 11 Jul 2011 08:35:25 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of philip.eardley@bt.com > Sent: 11 July 2011 09:22 > To: karagian@cs.utwente.nl; bob.briscoe@bt.com > Cc: conex@ietf.org > Subject: Re: [conex] Non-goals and/or misconceptions for conex- > concepts-uses > > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 09 July 2011 21:44 > To: Eardley,PL,Philip,DES8 R; Briscoe,RJ,Bob,DES8 R > Cc: conex@ietf.org > Subject: RE: [conex] Non-goals and/or misconceptions for conex- > concepts-uses > > Hi Phil, > > Thanks, please see in line! > > > On 7/9/2011, "philip.eardley@bt.com" wrote: > > >Conex enables IP nodes to see information about the whole path > congestion, so that it is visible as a useful metric; for example to > inform the operator's traffic management. > > > >In order to achieve this, the sender signals the information at the > transport layer. > > Georgios: Okay, but in my opinin this should be done for TCP and non- > TCP > based applications, see my previous email. > > >The WG is chartered to define this signalling for the TCP transport. > It would clearly be possible to also define this signalling for non-TCP > transports > > Georgios: Okay, but does this mean that Conex rechartering is needed in > order to achieve this? > > [phil] Yes. > I think the activity Richard suggests could be valuable, but it is > outside the charter as I read it. i remember there was a discussion > during chartering and it was decided to restrict to TCP, since this > represents the bulk of the traffic. {TM} I think the restriction was also imposed to try and ensure the WG gets something out the door quickly. As I remember the idea was that TCP would then provide the canonical example and other transports would then be added afterwards. Having said that there is nothing stopping Georgios or Richard from trying to conduct a survey of that sort as it will (hopefully) be useful in the future. Toby > phil > > Best regards, > Goergios > > > > > >phil > > > >________________________________________ > >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of > Georgios Karagiannis [karagian@cs.utwente.nl] > >Sent: 09 July 2011 07:18 > >To: Briscoe,RJ,Bob,DES8 R > >Cc: conex@ietf.org > >Subject: Re: [conex] Non-goals and/or misconceptions for conex- > concepts-uses > > > >Hi Bob, > > > >The text looks good, but I have one comment associated with the > following > >paragraph: > > > > > Capacity provisioning in relation to ConEx is another area of > > > confusion. Congestion-based traffic management is not an > alternative > > > to good capacity provisioning. Either or both can be good > practice > > > depending on the situation, and ConEx can provide a useful metric > for > > > both (see Section 5.4). > > > > > >Will the features provided Connex apply only to applications that are > >using TCP as a transport protocol? > >In other words, will the Conex useful metric, mentioned in the > paragraph > >above, be used by capacity provisioning and congestion-based traffic > >management only for applcations that are using TCP as transport > protocol > >(and not for applications that are using a non-TCP transport > protocol)? > > > >If the answer is yes, then please see below: > > > > > >Consider now that there are applications that use a non-TCP protocol, > >e.g., DCCP, that are generating a lot of traffic and are the main > causes > >of congestion in the network. > > > >Since the capacity provisioning and congestion-based traffic > management > >will not be able to use the Conex metrics, then the behaviour of the > >non-TCP applications that are generating the congestion cannot be > >effectively "controled" by using the augmented features provided by > >Conex. > >In this case for these non-TCP based applications only the current > means > >of providing congestion control and capacity provisioning can be used. > > > >It might also mean that only the applications that are using TCP as > >transport protocol will be effectively "controlled", while they > >should'nt. > > > >Best regards, > >Georgios > > > > > > > >On 7/7/2011, "Bob Briscoe" wrote: > > > >>Phil & all, > >> > >>I've decided the question & answer style broke up the flow. So here > >>it is re-written in prose and much shorter cos I've cut out chunks > >>that weren't really nec (e.g. utilisation != congestion)... > >> > >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \ > >>2.2. Non-Goals of ConEx and Common Misconceptions > >> > >> Congestion exposure is about the transport sender exposing > congestion > >> to the network, not the other way round. That would not make > sense > >> given by design the transport endpoints handle congestion in the > >> TCP/IP protocol suite. > >> > >> Nonetheless, it is a non-goal for IP layer devices to use this > ConEx > >> information to do fine-grained congestion control. That is still > >> best done at the transport sender. There is also no expectation > that > >> the information will be used by every IP router and forwarding > >> device. More likely, specific ConEx-based functions like traffic > >> management will be added to edge routers. This in turn should > >> incentivize end-system transports to be more careful about > congesting > >> others. > >> > >> Note that good behaviour at individual flow granularity is the > >> intended outcome, not the forcing function--it is the end, not > the > >> means. Enforcing per-flow compliance to the TCP congestion > response > >> (or any per-flow rate enforcement) is a non-goal: > >> > >> o It used to be commonly believed that TCP-friendliness was > critical > >> to fairness on the Internet. However, a particular congestion > >> control algorithm doesn't determine how much data an > application > >> transfers, or how many flows it opens, or which congestion > control > >> algorithm an application uses, or how many applications the > user > >> runs, or how many users are active at once. These factors all > >> have a stronger impact on how great a share of a link is > available > >> for any particular data transfer. To achieve fairness at this > >> broader granularity (between users, homes, sites or whole > >> networks) requires that individual flows in the same > bottleneck > >> will sometimes be very unequal. > >> > >> o If the network forced everything to be TCP-friendly, some > >> important applications would not work. Worse still, this > would > >> prevent deployment of higher performance replacements to TCP. > It > >> is important to allow give and take between one user's flows: > some > >> > >> > >> > >>Briscoe & Woundy Expires January 5, 2012 [Page > 7] > >> > >>Internet-Draft ConEx Mechanism July > 2011 > >> > >> > >> can be more aggressive than TCP and others less, e.g. long > >> transfers, following the example of LEDBAT [LEDBAT] (see > >> Section 5.2). > >> > >> Therefore, network enforcement of per-flow fairness is not only a > >> non-goal, it would be a harmful goal in many respects. > >> > >> Capacity provisioning in relation to ConEx is another area of > >> confusion. Congestion-based traffic management is not an > alternative > >> to good capacity provisioning. Either or both can be good > practice > >> depending on the situation, and ConEx can provide a useful metric > for > >> both (see Section 5.4). > >> > >> However, removing congestion from _all_ parts of a network is > >> unlikely to be a goal. If an end-to-end transport protocol > cannot go > >> fast enough to cause congestion somewhere along the path, it is > >> probably broken. A good transport protocol will continue to > >> accelerate until it encounters a bottleneck--typically in an > access > >> network (or all too often in the receiver's buffer, but that's > >> another story). Low levels of congestion _somewhere_ are > therefore > >> healthy. Just to be clear though, zero congestion somewhere > (e.g. the > >> core) is also perfectly healthy. > >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \ > >> > >> > >> > >>At 13:34 07/07/2011, philip.eardley@bt.com wrote: > >>>Your suggestions look good. > >>>Personally would put them later. A good, simple explanation of what > >>>conex is about should reduce the chances of a reader being > >>>misconceived. You could always put an advert early in the doc > >>> > >>>Cong & utilisation - would make this a question in its own right. > >>>I'd expand it a bit. Explain how acting assuming it's one (& in fact > >>>it's the other) leads to wrong 'cures'. > >>> > >>>Network traffic mgt does congestion control? - the bullet could be > >>>clearer. TM can be on just as fast timescales as cong control. the > >>>"arbitrate overall fairness" point is only one possibility for how > >>>TM can use conex info (& the next bullet explains that case) > >>> > >>>I'm not sure the first question is quite right, but am not inspired > >>>with an alternative at the moment > >>> > >>> > >>>-----Original Message----- > >> > >>________________________________________________________________ > >>Bob Briscoe, BT Innovate & Design > >> > >>_______________________________________________ > >>conex mailing list > >>conex@ietf.org > >>https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Mon Jul 11 08:17: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 8EDA021F8CE4 for ; Mon, 11 Jul 2011 08:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] 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 jFcwuTK-oiqA for ; Mon, 11 Jul 2011 08:17:55 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id C622021F8B9D for ; Mon, 11 Jul 2011 08:17:44 -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 p6BFFwdM026266; Mon, 11 Jul 2011 17:15:58 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 11 Jul 2011 15:17:44 +0000 To: "Toby Moncaster" , "philip.eardley@bt.com" , "bob.briscoe@bt.com" Date: Mon, 11 Jul 2011 15:17:44 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <002a01cc3fa5$76f6eef0$64e4ccd0$@com> 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]); Mon, 11 Jul 2011 17:16:10 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] Non-goals and/or misconceptions for 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, 11 Jul 2011 15:17:56 -0000 Hi Toby, Hi Phil, Thanks for the information! Maybe is good to have a f2f discussion in Quebec about this topic! I am very much ineterested in working on it! Best regards, Georgios On 7/11/2011, "Toby Moncaster" wrote: > > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf >> Of philip.eardley@bt.com >> Sent: 11 July 2011 09:22 >> To: karagian@cs.utwente.nl; bob.briscoe@bt.com >> Cc: conex@ietf.org >> Subject: Re: [conex] Non-goals and/or misconceptions for conex- >> concepts-uses >> >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 09 July 2011 21:44 >> To: Eardley,PL,Philip,DES8 R; Briscoe,RJ,Bob,DES8 R >> Cc: conex@ietf.org >> Subject: RE: [conex] Non-goals and/or misconceptions for conex- >> concepts-uses >> >> Hi Phil, >> >> Thanks, please see in line! >> >> >> On 7/9/2011, "philip.eardley@bt.com" wrote: >> >> >Conex enables IP nodes to see information about the whole path >> congestion, so that it is visible as a useful metric; for example to >> inform the operator's traffic management. >> > >> >In order to achieve this, the sender signals the information at the >> transport layer. >> >> Georgios: Okay, but in my opinin this should be done for TCP and non- >> TCP >> based applications, see my previous email. >> >> >The WG is chartered to define this signalling for the TCP transport. >> It would clearly be possible to also define this signalling for non-TCP >> transports >> >> Georgios: Okay, but does this mean that Conex rechartering is needed in >> order to achieve this? >> >> [phil] Yes. >> I think the activity Richard suggests could be valuable, but it is >> outside the charter as I read it. i remember there was a discussion >> during chartering and it was decided to restrict to TCP, since this >> represents the bulk of the traffic. > >{TM} I think the restriction was also imposed to try and ensure the WG gets >something out the door quickly. As I remember the idea was that TCP would >then provide the canonical example and other transports would then be added >afterwards. > >Having said that there is nothing stopping Georgios or Richard from trying >to conduct a survey of that sort as it will (hopefully) be useful in the >future. > >Toby > > >> phil >> >> Best regards, >> Goergios >> >> >> > >> >phil >> > >> >________________________________________ >> >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of >> Georgios Karagiannis [karagian@cs.utwente.nl] >> >Sent: 09 July 2011 07:18 >> >To: Briscoe,RJ,Bob,DES8 R >> >Cc: conex@ietf.org >> >Subject: Re: [conex] Non-goals and/or misconceptions for conex- >> concepts-uses >> > >> >Hi Bob, >> > >> >The text looks good, but I have one comment associated with the >> following >> >paragraph: >> > >> > > Capacity provisioning in relation to ConEx is another area of >> > > confusion. Congestion-based traffic management is not an >> alternative >> > > to good capacity provisioning. Either or both can be good >> practice >> > > depending on the situation, and ConEx can provide a useful metric >> for >> > > both (see Section 5.4). >> > >> > >> >Will the features provided Connex apply only to applications that are >> >using TCP as a transport protocol? >> >In other words, will the Conex useful metric, mentioned in the >> paragraph >> >above, be used by capacity provisioning and congestion-based traffic >> >management only for applcations that are using TCP as transport >> protocol >> >(and not for applications that are using a non-TCP transport >> protocol)? >> > >> >If the answer is yes, then please see below: >> > >> > >> >Consider now that there are applications that use a non-TCP protocol, >> >e.g., DCCP, that are generating a lot of traffic and are the main >> causes >> >of congestion in the network. >> > >> >Since the capacity provisioning and congestion-based traffic >> management >> >will not be able to use the Conex metrics, then the behaviour of the >> >non-TCP applications that are generating the congestion cannot be >> >effectively "controled" by using the augmented features provided by >> >Conex. >> >In this case for these non-TCP based applications only the current >> means >> >of providing congestion control and capacity provisioning can be used. >> > >> >It might also mean that only the applications that are using TCP as >> >transport protocol will be effectively "controlled", while they >> >should'nt. >> > >> >Best regards, >> >Georgios >> > >> > >> > >> >On 7/7/2011, "Bob Briscoe" wrote: >> > >> >>Phil & all, >> >> >> >>I've decided the question & answer style broke up the flow. So here >> >>it is re-written in prose and much shorter cos I've cut out chunks >> >>that weren't really nec (e.g. utilisation !=3D congestion)... >> >> >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >> \ >> >>2.2. Non-Goals of ConEx and Common Misconceptions >> >> >> >> Congestion exposure is about the transport sender exposing >> congestion >> >> to the network, not the other way round. That would not make >> sense >> >> given by design the transport endpoints handle congestion in the >> >> TCP/IP protocol suite. >> >> >> >> Nonetheless, it is a non-goal for IP layer devices to use this >> ConEx >> >> information to do fine-grained congestion control. That is still >> >> best done at the transport sender. There is also no expectation >> that >> >> the information will be used by every IP router and forwarding >> >> device. More likely, specific ConEx-based functions like traffic >> >> management will be added to edge routers. This in turn should >> >> incentivize end-system transports to be more careful about >> congesting >> >> others. >> >> >> >> Note that good behaviour at individual flow granularity is the >> >> intended outcome, not the forcing function--it is the end, not >> the >> >> means. Enforcing per-flow compliance to the TCP congestion >> response >> >> (or any per-flow rate enforcement) is a non-goal: >> >> >> >> o It used to be commonly believed that TCP-friendliness was >> critical >> >> to fairness on the Internet. However, a particular congestion >> >> control algorithm doesn't determine how much data an >> application >> >> transfers, or how many flows it opens, or which congestion >> control >> >> algorithm an application uses, or how many applications the >> user >> >> runs, or how many users are active at once. These factors all >> >> have a stronger impact on how great a share of a link is >> available >> >> for any particular data transfer. To achieve fairness at this >> >> broader granularity (between users, homes, sites or whole >> >> networks) requires that individual flows in the same >> bottleneck >> >> will sometimes be very unequal. >> >> >> >> o If the network forced everything to be TCP-friendly, some >> >> important applications would not work. Worse still, this >> would >> >> prevent deployment of higher performance replacements to TCP. >> It >> >> is important to allow give and take between one user's flows: >> some >> >> >> >> >> >> >> >>Briscoe & Woundy Expires January 5, 2012 [Page >> 7] >> >> >> >>Internet-Draft ConEx Mechanism July >> 2011 >> >> >> >> >> >> can be more aggressive than TCP and others less, e.g. long >> >> transfers, following the example of LEDBAT [LEDBAT] (see >> >> Section 5.2). >> >> >> >> Therefore, network enforcement of per-flow fairness is not only a >> >> non-goal, it would be a harmful goal in many respects. >> >> >> >> Capacity provisioning in relation to ConEx is another area of >> >> confusion. Congestion-based traffic management is not an >> alternative >> >> to good capacity provisioning. Either or both can be good >> practice >> >> depending on the situation, and ConEx can provide a useful metric >> for >> >> both (see Section 5.4). >> >> >> >> However, removing congestion from _all_ parts of a network is >> >> unlikely to be a goal. If an end-to-end transport protocol >> cannot go >> >> fast enough to cause congestion somewhere along the path, it is >> >> probably broken. A good transport protocol will continue to >> >> accelerate until it encounters a bottleneck--typically in an >> access >> >> network (or all too often in the receiver's buffer, but that's >> >> another story). Low levels of congestion _somewhere_ are >> therefore >> >> healthy. Just to be clear though, zero congestion somewhere >> (e.g. the >> >> core) is also perfectly healthy. >> >>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ >> \ >> >> >> >> >> >> >> >>At 13:34 07/07/2011, philip.eardley@bt.com wrote: >> >>>Your suggestions look good. >> >>>Personally would put them later. A good, simple explanation of what >> >>>conex is about should reduce the chances of a reader being >> >>>misconceived. You could always put an advert early in the doc >> >>> >> >>>Cong & utilisation - would make this a question in its own right. >> >>>I'd expand it a bit. Explain how acting assuming it's one (& in fact >> >>>it's the other) leads to wrong 'cures'. >> >>> >> >>>Network traffic mgt does congestion control? - the bullet could be >> >>>clearer. TM can be on just as fast timescales as cong control. the >> >>>"arbitrate overall fairness" point is only one possibility for how >> >>>TM can use conex info (& the next bullet explains that case) >> >>> >> >>>I'm not sure the first question is quite right, but am not inspired >> >>>with an alternative at the moment >> >>> >> >>> >> >>>-----Original Message----- >> >> >> >>________________________________________________________________ >> >>Bob Briscoe, BT Innovate & Design >> >> >> >>_______________________________________________ >> >>conex mailing list >> >>conex@ietf.org >> >>https://www.ietf.org/mailman/listinfo/conex >> >_______________________________________________ >> >conex mailing list >> >conex@ietf.org >> >https://www.ietf.org/mailman/listinfo/conex >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Mon Jul 11 08:51: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 0305121F8ABE for ; Mon, 11 Jul 2011 08:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SARE_SUB_ENC_UTF8=0.152] 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 FPxn4dWSOQAJ for ; Mon, 11 Jul 2011 08:51:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id DD48421F8771 for ; Mon, 11 Jul 2011 08:51:55 -0700 (PDT) Received: from [10.0.10.88] (88-96-99-198.dsl.in-addr.zen.co.uk [88.96.99.198]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MMFUT-1QaUwW37wD-0082v2; Mon, 11 Jul 2011 17:51:54 +0200 To: "=?utf-8?B?R2Vvcmdpb3MgS2FyYWdpYW5uaXM=?=" , "=?utf-8?B?cGhpbGlwLmVhcmRsZXlAYnQuY29t?=" , "=?utf-8?B?Ym9iLmJyaXNjb2VAYnQuY29t?=" From: "=?utf-8?B?VG9ieSBNb25jYXN0ZXI=?=" Date: Mon, 11 Jul 2011 16:50:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1310399459134" Message-Id: <0MMFUT-1QaUwW37wD-0082v2@mrelayeu.kundenserver.de> X-Provags-ID: V02:K0:EuMkesz/oAbsA33mKF5pPnClNz3ZRInCTkSWA5/O/MG aaV/nFUvPcbE5P8/KKQ9wiZzG6SYBYuOfbfjdeH/P1LfUKUot7 4hcMhJy4gS32IxhlyHbWOZ4+hE4VZaT8p491sNtA/KC5auvmWv exIuStvFJCDigO1MRHUvBCxmiH1VfHRx4imJuvoyjuKUZsAbYw VHBlIfBUML8ErEcVoOfAJJtXSjzidBJf2LRHnbbF/4= Cc: =?utf-8?B?Y29uZXhAaWV0Zi5vcmc=?= Subject: Re: [conex] =?utf-8?q?Non-goals_and/or_misconceptions_for_conex-conce?= =?utf-8?q?pts-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, 11 Jul 2011 15:51:58 -0000 ------=_Part_0_1310399459134 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U2FkbHkgSSB3b24ndCBiZSB0aGVyZSBpbiBRdWViZWMKClNlbnQgZnJvbSBteSBIVEMKCi0tLS0t IFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogIkdlb3JnaW9zIEthcmFnaWFubmlzIiA8a2FyYWdp YW5AY3MudXR3ZW50ZS5ubD4KRGF0ZTogTW9uLCBKdWwgMTEsIDIwMTEgMTY6MTcKU3ViamVjdDog W2NvbmV4XSBOb24tZ29hbHMgYW5kL29yIG1pc2NvbmNlcHRpb25zIGZvciBjb25leC1jb25jZXB0 cy11c2VzClRvOiAiVG9ieSBNb25jYXN0ZXIiIDx0b2J5QG1vbmNhc3Rlci5jb20+LCAicGhpbGlw LmVhcmRsZXlAYnQuY29tIiA8cGhpbGlwLmVhcmRsZXlAYnQuY29tPiwgImJvYi5icmlzY29lQGJ0 LmNvbSIgPGJvYi5icmlzY29lQGJ0LmNvbT4KQ2M6ICJjb25leEBpZXRmLm9yZyIgPGNvbmV4QGll dGYub3JnPgoKCkhpIFRvYnksIEhpIFBoaWwsCgpUaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbiEK Ck1heWJlIGlzIGdvb2QgdG8gaGF2ZSBhIGYyZiBkaXNjdXNzaW9uIGluIFF1ZWJlYyBhYm91dCB0 aGlzIHRvcGljIQoKSSBhbSB2ZXJ5IG11Y2ggaW5ldGVyZXN0ZWQgaW4gd29ya2luZyBvbiBpdCEK CkJlc3QgcmVnYXJkcywKR2Vvcmdpb3MKCgoKT24gNy8xMS8yMDExLCAiVG9ieSBNb25jYXN0ZXIi IDx0b2J5QG1vbmNhc3Rlci5jb20+IHdyb3RlOgoKPgo+Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tCj4+IEZyb206IGNvbmV4LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb25leC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYKPj4gT2YgcGhpbGlwLmVhcmRsZXlAYnQuY29tCj4+IFNl bnQ6IDExIEp1bHkgMjAxMSAwOToyMgo+PiBUbzoga2FyYWdpYW5AY3MudXR3ZW50ZS5ubDsgYm9i LmJyaXNjb2VAYnQuY29tCj4+IENjOiBjb25leEBpZXRmLm9yZwo+PiBTdWJqZWN0OiBSZTogW2Nv bmV4XSBOb24tZ29hbHMgYW5kL29yIG1pc2NvbmNlcHRpb25zIGZvciBjb25leC0KPj4gY29uY2Vw dHMtdXNlcwo+Pgo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+PiBGcm9tOiBHZW9yZ2lv cyBLYXJhZ2lhbm5pcyBbbWFpbHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmxdCj4+IFNlbnQ6IDA5 IEp1bHkgMjAxMSAyMTo0NAo+PiBUbzogRWFyZGxleSxQTCxQaGlsaXAsREVTOCBSOyBCcmlzY29l LFJKLEJvYixERVM4IFIKPj4gQ2M6IGNvbmV4QGlldGYub3JnCj4+IFN1YmplY3Q6IFJFOiBbY29u ZXhdIE5vbi1nb2FscyBhbmQvb3IgbWlzY29uY2VwdGlvbnMgZm9yIGNvbmV4LQo+PiBjb25jZXB0 cy11c2VzCj4+Cj4+IEhpIFBoaWwsCj4+Cj4+IFRoYW5rcywgcGxlYXNlIHNlZSBpbiBsaW5lIQo+ Pgo+Pgo+PiBPbiA3LzkvMjAxMSwgInBoaWxpcC5lYXJkbGV5QGJ0LmNvbSIgPHBoaWxpcC5lYXJk bGV5QGJ0LmNvbT4gd3JvdGU6Cj4+Cj4+ID5Db25leCBlbmFibGVzIElQIG5vZGVzIHRvIHNlZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgd2hvbGUgcGF0aAo+PiBjb25nZXN0aW9uLCBzbyB0aGF0IGl0 IGlzIHZpc2libGUgYXMgYSB1c2VmdWwgbWV0cmljOyBmb3IgZXhhbXBsZSB0bwo+PiBpbmZvcm0g dGhlIG9wZXJhdG9yJ3MgdHJhZmZpYyBtYW5hZ2VtZW50Lgo+PiA+Cj4+ID5JbiBvcmRlciB0byBh Y2hpZXZlIHRoaXMsIHRoZSBzZW5kZXIgc2lnbmFscyB0aGUgaW5mb3JtYXRpb24gYXQgdGhlCj4+ IHRyYW5zcG9ydCBsYXllci4KPj4KPj4gR2Vvcmdpb3M6IE9rYXksIGJ1dCBpbiBteSBvcGluaW4g dGhpcyBzaG91bGQgYmUgZG9uZSBmb3IgVENQIGFuZCBub24tCj4+IFRDUAo+PiBiYXNlZCBhcHBs aWNhdGlvbnMsIHNlZSBteSBwcmV2aW91cyBlbWFpbC4KPj4KPj4gPlRoZSBXRyBpcyBjaGFydGVy ZWQgdG8gZGVmaW5lIHRoaXMgc2lnbmFsbGluZyBmb3IgdGhlIFRDUCB0cmFuc3BvcnQuCj4+IEl0 IHdvdWxkIGNsZWFybHkgYmUgcG9zc2libGUgdG8gYWxzbyBkZWZpbmUgdGhpcyBzaWduYWxsaW5n IGZvciBub24tVENQCj4+IHRyYW5zcG9ydHMKPj4KPj4gR2Vvcmdpb3M6IE9rYXksIGJ1dCBkb2Vz IHRoaXMgbWVhbiB0aGF0IENvbmV4IHJlY2hhcnRlcmluZyBpcyBuZWVkZWQgaW4KPj4gb3JkZXIg dG8gYWNoaWV2ZSB0aGlzPwo+Pgo+PiBbcGhpbF0gWWVzLgo+PiBJIHRoaW5rIHRoZSBhY3Rpdml0 eSBSaWNoYXJkIHN1Z2dlc3RzIGNvdWxkIGJlIHZhbHVhYmxlLCBidXQgaXQgaXMKPj4gb3V0c2lk ZSB0aGUgY2hhcnRlciBhcyBJIHJlYWQgaXQuIGkgcmVtZW1iZXIgdGhlcmUgd2FzIGEgZGlzY3Vz c2lvbgo+PiBkdXJpbmcgY2hhcnRlcmluZyBhbmQgaXQgd2FzIGRlY2lkZWQgdG8gcmVzdHJpY3Qg dG8gVENQLCBzaW5jZSB0aGlzCj4+IHJlcHJlc2VudHMgdGhlIGJ1bGsgb2YgdGhlIHRyYWZmaWMu Cj4KPntUTX0gSSB0aGluayB0aGUgcmVzdHJpY3Rpb24gd2FzIGFsc28gaW1wb3NlZCB0byB0cnkg YW5kIGVuc3VyZSB0aGUgV0cgZ2V0cwo+c29tZXRoaW5nIG91dCB0aGUgZG9vciBxdWlja2x5LiBB cyBJIHJlbWVtYmVyIHRoZSBpZGVhIHdhcyB0aGF0IFRDUCB3b3VsZAo= ------=_Part_0_1310399459134 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U2FkbHkgSSB3b24mIzM5O3QgYmUgdGhlcmUgaW4gUXVlYmVjPGJyPjxicj5TZW50IGZyb20gbXkg SFRDPGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90O0dlb3Jn aW9zIEthcmFnaWFubmlzJnF1b3Q7ICZsdDtrYXJhZ2lhbkBjcy51dHdlbnRlLm5sJmd0Ozxicj5E YXRlOiBNb24sIEp1bCAxMSwgMjAxMSAxNjoxNzxicj5TdWJqZWN0OiBbY29uZXhdIE5vbi1nb2Fs cyBhbmQvb3IgbWlzY29uY2VwdGlvbnMgZm9yIGNvbmV4LWNvbmNlcHRzLXVzZXM8YnI+VG86ICZx dW90O1RvYnkgTW9uY2FzdGVyJnF1b3Q7ICZsdDt0b2J5QG1vbmNhc3Rlci5jb20mZ3Q7LCAmcXVv dDtwaGlsaXAuZWFyZGxleUBidC5jb20mcXVvdDsgJmx0O3BoaWxpcC5lYXJkbGV5QGJ0LmNvbSZn dDssICZxdW90O2JvYi5icmlzY29lQGJ0LmNvbSZxdW90OyAmbHQ7Ym9iLmJyaXNjb2VAYnQuY29t Jmd0Ozxicj5DYzogJnF1b3Q7Y29uZXhAaWV0Zi5vcmcmcXVvdDsgJmx0O2NvbmV4QGlldGYub3Jn Jmd0Ozxicj48YnI+PGJyPkhpIFRvYnksIEhpIFBoaWwsPGJyPjxicj5UaGFua3MgZm9yIHRoZSBp bmZvcm1hdGlvbiE8YnI+PGJyPk1heWJlIGlzIGdvb2QgdG8gaGF2ZSBhIGYyZiBkaXNjdXNzaW9u IGluIFF1ZWJlYyBhYm91dCB0aGlzIHRvcGljITxicj48YnI+SSBhbSB2ZXJ5IG11Y2ggaW5ldGVy ZXN0ZWQgaW4gd29ya2luZyBvbiBpdCE8YnI+PGJyPkJlc3QgcmVnYXJkcyw8YnI+R2Vvcmdpb3M8 YnI+PGJyPjxicj48YnI+T24gNy8xMS8yMDExLCAmcXVvdDtUb2J5IE1vbmNhc3RlciZxdW90OyAm bHQ7dG9ieUBtb25jYXN0ZXIuY29tJmd0OyB3cm90ZTo8YnI+PGJyPiZndDs8YnI+Jmd0Ozxicj4m Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7Jmd0OyBGcm9tOiBjb25l eC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29uZXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmPGJyPiZndDsmZ3Q7IE9mIHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxicj4mZ3Q7Jmd0OyBTZW50 OiAxMSBKdWx5IDIwMTEgMDk6MjI8YnI+Jmd0OyZndDsgVG86IGthcmFnaWFuQGNzLnV0d2VudGUu bmw7IGJvYi5icmlzY29lQGJ0LmNvbTxicj4mZ3Q7Jmd0OyBDYzogY29uZXhAaWV0Zi5vcmc8YnI+ Jmd0OyZndDsgU3ViamVjdDogUmU6IFtjb25leF0gTm9uLWdvYWxzIGFuZC9vciBtaXNjb25jZXB0 aW9ucyBmb3IgY29uZXgtPGJyPiZndDsmZ3Q7IGNvbmNlcHRzLXVzZXM8YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsgRnJvbTogR2Vv cmdpb3MgS2FyYWdpYW5uaXMgW21haWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sXTxicj4mZ3Q7 Jmd0OyBTZW50OiAwOSBKdWx5IDIwMTEgMjE6NDQ8YnI+Jmd0OyZndDsgVG86IEVhcmRsZXksUEws UGhpbGlwLERFUzggUjsgQnJpc2NvZSxSSixCb2IsREVTOCBSPGJyPiZndDsmZ3Q7IENjOiBjb25l eEBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW2NvbmV4XSBOb24tZ29hbHMgYW5k L29yIG1pc2NvbmNlcHRpb25zIGZvciBjb25leC08YnI+Jmd0OyZndDsgY29uY2VwdHMtdXNlczxi cj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBIaSBQaGlsLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBU aGFua3MsIHBsZWFzZSBzZWUgaW4gbGluZSE8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0 OyZndDsgT24gNy85LzIwMTEsICZxdW90O3BoaWxpcC5lYXJkbGV5QGJ0LmNvbSZxdW90OyAmbHQ7 cGhpbGlwLmVhcmRsZXlAYnQuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsg Jmd0O0NvbmV4IGVuYWJsZXMgSVAgbm9kZXMgdG8gc2VlIGluZm9ybWF0aW9uIGFib3V0IHRoZSB3 aG9sZSBwYXRoPGJyPiZndDsmZ3Q7IGNvbmdlc3Rpb24sIHNvIHRoYXQgaXQgaXMgdmlzaWJsZSBh cyBhIHVzZWZ1bCBtZXRyaWM7IGZvciBleGFtcGxlIHRvPGJyPiZndDsmZ3Q7IGluZm9ybSB0aGUg b3BlcmF0b3ImIzM5O3MgdHJhZmZpYyBtYW5hZ2VtZW50Ljxicj4mZ3Q7Jmd0OyAmZ3Q7PGJyPiZn dDsmZ3Q7ICZndDtJbiBvcmRlciB0byBhY2hpZXZlIHRoaXMsIHRoZSBzZW5kZXIgc2lnbmFscyB0 aGUgaW5mb3JtYXRpb24gYXQgdGhlPGJyPiZndDsmZ3Q7IHRyYW5zcG9ydCBsYXllci48YnI+Jmd0 OyZndDs8YnI+Jmd0OyZndDsgR2Vvcmdpb3M6IE9rYXksIGJ1dCBpbiBteSBvcGluaW4gdGhpcyBz aG91bGQgYmUgZG9uZSBmb3IgVENQIGFuZCBub24tPGJyPiZndDsmZ3Q7IFRDUDxicj4mZ3Q7Jmd0 OyBiYXNlZCBhcHBsaWNhdGlvbnMsIHNlZSBteSBwcmV2aW91cyBlbWFpbC48YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDsgJmd0O1RoZSBXRyBpcyBjaGFydGVyZWQgdG8gZGVmaW5lIHRoaXMgc2lnbmFs bGluZyBmb3IgdGhlIFRDUCB0cmFuc3BvcnQuPGJyPiZndDsmZ3Q7IEl0IHdvdWxkIGNsZWFybHkg YmUgcG9zc2libGUgdG8gYWxzbyBkZWZpbmUgdGhpcyBzaWduYWxsaW5nIGZvciBub24tVENQPGJy PiZndDsmZ3Q7IHRyYW5zcG9ydHM8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgR2Vvcmdpb3M6IE9r YXksIGJ1dCBkb2VzIHRoaXMgbWVhbiB0aGF0IENvbmV4IHJlY2hhcnRlcmluZyBpcyBuZWVkZWQg aW48YnI+Jmd0OyZndDsgb3JkZXIgdG8gYWNoaWV2ZSB0aGlzPzxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyBbcGhpbF0gWWVzLjxicj4mZ3Q7Jmd0OyBJIHRoaW5rIHRoZSBhY3Rpdml0eSBSaWNoYXJk IHN1Z2dlc3RzIGNvdWxkIGJlIHZhbHVhYmxlLCBidXQgaXQgaXM8YnI+Jmd0OyZndDsgb3V0c2lk ZSB0aGUgY2hhcnRlciBhcyBJIHJlYWQgaXQuIGkgcmVtZW1iZXIgdGhlcmUgd2FzIGEgZGlzY3Vz c2lvbjxicj4mZ3Q7Jmd0OyBkdXJpbmcgY2hhcnRlcmluZyBhbmQgaXQgd2FzIGRlY2lkZWQgdG8g cmVzdHJpY3QgdG8gVENQLCBzaW5jZSB0aGlzPGJyPiZndDsmZ3Q7IHJlcHJlc2VudHMgdGhlIGJ1 bGsgb2YgdGhlIHRyYWZmaWMuPGJyPiZndDs8YnI+Jmd0O3tUTX0gSSB0aGluayB0aGUgcmVzdHJp Y3Rpb24gd2FzIGFsc28gaW1wb3NlZCB0byB0cnkgYW5kIGVuc3VyZSB0aGUgV0cgZ2V0czxicj4m Z3Q7c29tZXRoaW5nIG91dCB0aGUgZG9vciBxdWlja2x5LiBBcyBJIHJlbWVtYmVyIHRoZSBpZGVh IHdhcyB0aGF0IFRDUCB3b3VsZDxicj48YnI+PGJyPg== ------=_Part_0_1310399459134-- From bob.briscoe@bt.com Mon Jul 11 10:14: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 BEC3911E8102 for ; Mon, 11 Jul 2011 10:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 VzJcyMRzBwW7 for ; Mon, 11 Jul 2011 10:14:23 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6924011E80FC for ; Mon, 11 Jul 2011 10:14:20 -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, 11 Jul 2011 18:14:19 +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, 11 Jul 2011 18:14:19 +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 1310404459988; Mon, 11 Jul 2011 18:14:19 +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 p6BHEG5t016930 for ; Mon, 11 Jul 2011 18:14:16 +0100 Message-Id: <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jul 2011 18:14:22 +0100 To: From: Bob Briscoe In-Reply-To: <7.1.0.9.2.20110707180350.078f2a60@bt.com> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@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: 11 Jul 2011 17:14:19.0020 (UTC) FILETIME=[F829F4C0:01CC3FED] Subject: [conex] New concepts text 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, 11 Jul 2011 17:14:24 -0000 All, Please give feedback on the proposed new Concepts text below that precedes the definitions. Altho the doc is meant to be about concepts, in -01 the main concepts were defined but not explained. So, I felt the definitions smacked you in the face without any warning, and it wasn't ever explained why you needed them. I've also pasted proposed changes to the definitions section below, because I've changed a couple of definitions: - I've clarified the definition of congestion, because there were three conflicting statements: in the introduction, the definitions section and abstract-mech. - I've made a big change to congestion-volume, which was previously defined as congestion-rate multiplied by time. I've also added the units each metric is measured in. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 2. Concepts Despite its central role in network control and management, congestion is a remarkably hard concept to define. [Bauer09] provides a good academic background. For the purposes of ConEx, the definition below focuses on how congestion would be measured, rather than precisely what it is. Our definition of congestion is then equivalent to the loss probability (or the marking probability if ECN is used). ConEx is essentially about accountability for congestion (or blame in crude language). The blame for congestion lies equally between too little capacity and too much traffic. On the capacity side, congestion itself measures how badly the network provider is to blame. On the traffic side, in a shared network, the blame is split among all the users. Congestion-volume measures how much of each user's traffic is to blame for the congestion. Note that congestion- volume is a property of traffic, whereas congestion is a property of a link or a path. Briscoe & Woundy Expires January 8, 2012 [Page 5] Internet-Draft ConEx Concepts & Use Cases July 2011 Congestion-volume is a relatively newly defined metric that is central to ConEx. To grasp an intuitive feel for what congestion- volume measures, some network operators give you an allowance and only count data volume during the peak period against it. This is equivalent to counting your congestion-volume by assuming that congestion is 100% during the peak period and 0% otherwise. The congestion-volume metric is more refined but broadly equivalent, and still as simple to measure as the above time-of-day volume. Imagine Alice sends 1GB while the loss-probability is a constant 0.2%. Then her contribution to congestion (or congestion-volume) is 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is 0.1%, this adds 3MB to her congestion-volume. Her total contribution to congestion is then 2MB+3MB = 5MB. To measure Alice's congestion-volume no-one has to do all these multiplications and additions. It is simply a matter of counting the total volume of Alice's traffic that was discarded (a queue with a percentage loss involves multiplication inherently). Finally, there is yet another way to cut the blame for congestion. Recall that the level of congestion itself measures the provider's blame. However, in an internetwork there are multiple providers. If a data centre network with zero congestion is connected to an access network and sends traffic over a link with 0.4% loss probability, then clearly all the blame for congestion lies with the access network. However, at another time, there might be 0.1% congestion across the data centre and 0.7% across the access, making 0.8% end- to-end congestion across the path. In order to apportion blame accordingly, ConEx is designed so that a meter at the border can see how much of the congestion is on one side or other, termed upstream and downstream congestion. If A and B are connected within a chain of more than two networks, A attributes all congestion beyond B to B, and vice versa. As far as A is concerned, B chooses who to route to, so B takes responsibility for its choices. 2.1. Definitions Congestion: Congestion occurs when any user's traffic suffers increased delay, loss or ECN marking as a result of one or more network resources becoming overloaded. For the purposes of ConEx, the focus is on concrete signals of congestion (ECN and loss), therefore delay is set to one side. Congestion is measured as the probability of loss or the probability of ECN marking, usually expressed as dimensionless percentages. Briscoe & Woundy Expires January 8, 2012 [Page 6] Internet-Draft ConEx Concepts & Use Cases July 2011 Congestion-volume: For any granularity of traffic (packet, flow, aggregate, link, etc.), the volume of bytes dropped or marked in a given period of time. Conceptually, data volume multiplied by the instantaneous congestion each packet of the volume experienced. Usually expressed in bytes (or MB, GB, of course). Congestion-rate: For any granularity of traffic (packet, flow, aggregate, link, etc.), the instantaneous rate of traffic discarded or marked due to congestion. Conceptually, the instantaneous bit-rate of the traffic weighted by the instantaneous congestion it experiences. Usually expressed in b/s. Upstream Congestion: The accumulated level of congestion experienced by a traffic flow thus far, relative to a point along its path. In other words, at any point the Upstream Congestion is the accmulated level of congestion the traffic flow has experienced as it travels from the sender to that point. At the receiver this is equivalent to the end-to-end congestion level that (usually) is reported back to the sender. Downstream Congestion: The level of congestion a flow of traffic is expected to experience on the remainder of its path. In other words, at any point the Downstream Congestion is the level of congestion the traffic flow is yet to experience as it travels from that point to the receiver. Aka. Rest-of-Path Congestion. Consumer: A general term representing the contractual entity such as a user or business or institution that uses the service of a network provider. There is no implication that the contract has to be commercial; for instance the consumers of a University or enterprise network service would be students or employees and they might well be required to comply with some form of contract or acceptable use policy. There is also no implication that the consumer is necessarily an end-consumer. Where two networks form a customer-provider relationship, the term consumer is also intended to cover the customer network. Network provider: (also 'operator'): the term is not confined to Internet service providers (ISPs) who run commercial public networks but is also intended to generalise to operators of enterprise, campus and other networks. [ConEx-Abstract-Mech] gives further definitions for aspects of ConEx to do with protocol mechanisms. Briscoe & Woundy Expires January 8, 2012 [Page 7] Internet-Draft ConEx Concepts & Use Cases July 2011 2.2. Non-Goals of ConEx and Common Misconceptions [continues as pasted into an earlier thread...] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob At 18:45 07/07/2011, Bob Briscoe wrote: >Phil, > >>Other comments: >>'concepts' rather than 'definitions' is great. The current page >>count in the ToC suggests you only have text under 'definitions'. >>Suggest you work as much as possible, ie describe the concepts! ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Jul 11 15:51: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 F113C11E8312 for ; Mon, 11 Jul 2011 15:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 5cQoHuB3SSqk for ; Mon, 11 Jul 2011 15:51:45 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7511E80F4 for ; Mon, 11 Jul 2011 15:51:44 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jul 2011 23:51:43 +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); Mon, 11 Jul 2011 23:51:42 +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 1310424697738; Mon, 11 Jul 2011 23:51:37 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.73]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6BMpaGS017824; Mon, 11 Jul 2011 23:51:37 +0100 Message-Id: <201107112251.p6BMpaGS017824@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jul 2011 23:51:35 +0100 To: John Leslie , Toby Moncaster 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: 11 Jul 2011 22:51:42.0899 (UTC) FILETIME=[1A74C030:01CC401D] Cc: ConEx IETF list Subject: [conex] ConEx is not the only solution? 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, 11 Jul 2011 22:51:46 -0000 John, Toby, In the introduction to the main ConEx use cases (inform traffic mgmt, incentivise LEDBAT & intra-class user-controlled QoS), it current says: "In most cases ConEx is not the only solution to achieve these. " I'd like to delete this sentence, as I don't believe it's true in these cases (unless one admits significantly inferior "solutions"). And it's a statement that is damning enough to get an activity stopped. As previous editors of conex-concepts-uses, was there some history behind including that sentence that I've missed? Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From internet-drafts@ietf.org Mon Jul 11 16:29: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 5291311E8383; Mon, 11 Jul 2011 16:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCWKTftWfEdz; Mon, 11 Jul 2011 16:29:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E36111E83BD; Mon, 11 Jul 2011 16:29:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711232910.21063.56381.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 16:29:10 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 23:29:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechan= ism Author(s) : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-02.txt Pages : 22 Date : 2011-07-11 This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, where it could, for example, be used to provide input to traffic management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-02.txt From internet-drafts@ietf.org Mon Jul 11 17:07: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 3CCBD11E8153; Mon, 11 Jul 2011 17:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpF0Tn68Zbj7; Mon, 11 Jul 2011 17:07:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82C721F8D9C; Mon, 11 Jul 2011 17:07:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110712000701.513.38329.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 17:07:01 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:07:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : ConEx Concepts and Use Cases Author(s) : Bob Briscoe Richard Woundy Filename : draft-ietf-conex-concepts-uses-02.txt Pages : 25 Date : 2011-07-11 This document provides the entry point to the set of documentation on a new Congestion Exposure (ConEx) protocol. It motivates a new ConEx field at the IP layer, focusing on the 'why' rather than the = 9;how'. In the absence of such a protocol, traffic is subjected to numerous traffic management checks and limits as it crosses the Internet. The purpose of this protocol is to expose congestion to network operators, so that they have no need to intervene at all when there is no congestion, and so they have exactly the right information when there is congestion. Then it will at least be possible for traffic management to be application-neutral, openly transparent and free of unnecessary restraints. Although traffic management is the focus of this document, it also briefly introduces a number of other important potential uses for ConEx, demonstrating its role as a generative technology and justifying its placement in the IP layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-02.txt From bob.briscoe@bt.com Mon Jul 11 17:21: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 EAD3311E817F for ; Mon, 11 Jul 2011 17:21:35 -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 pjoTXrYwR-02 for ; Mon, 11 Jul 2011 17:21:35 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 304CB11E8271 for ; Mon, 11 Jul 2011 17:21:35 -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, 12 Jul 2011 01:21: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); Tue, 12 Jul 2011 01:21: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 1310430089429; Tue, 12 Jul 2011 01:21:29 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.73]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6C0LVhk018091 for ; Tue, 12 Jul 2011 01:21:32 +0100 Message-Id: <201107120021.p6C0LVhk018091@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jul 2011 01:21:14 +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: 12 Jul 2011 00:21:33.0472 (UTC) FILETIME=[A77CEA00:01CC4029] Subject: [conex] Fwd: New Version Notification - draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:21:36 -0000 ConEx folks, We've posted a new -02 rev of conex-concepts-uses. >http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-02.txt > >Diff from previous version: >http://tools.ietf.org/rfcdiff?url2=draft-ietf-conex-concepts-uses-02 Main changes from draft-ietf-conex-concepts-uses-01 to -02: 1) Completely new Abstract & Introduction. 2) Concepts and Non-Goals sections added around existing slightly altered definitions. 3) Clarifications to Existing Traffic Management section and 4) Clarifications to Use-Cases section, with Other use Cases Added. 5) Deployment Arrangements Section added (but only bulletted content within it). We'd appreciate review comments, particularly on the most recent changes that haven't seen discussion on the list (2,3,4,5) We had hoped to produce a document that at least had no {ToDo} elements left in it, but it still needs another few hours work. Bob & Rich ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Mon Jul 11 17:26: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 F10F711E8385 for ; Mon, 11 Jul 2011 17:26:35 -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=[AWL=0.000, 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 G1Fod9nUOKEb for ; Mon, 11 Jul 2011 17:26:35 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 69BD411E8158 for ; Mon, 11 Jul 2011 17:26:35 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B8F0033C22; Mon, 11 Jul 2011 20:26:34 -0400 (EDT) Date: Mon, 11 Jul 2011 20:26:34 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110712002634.GB2822@verdi> References: <201107112251.p6BMpaGS017824@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107112251.p6BMpaGS017824@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] ConEx is not the only solution? 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: Tue, 12 Jul 2011 00:26:36 -0000 Bob Briscoe wrote: > > John, Toby, > > In the introduction to the main ConEx use cases (inform traffic mgmt, > incentivise LEDBAT & intra-class user-controlled QoS), it current says: > "In most cases ConEx is not the only solution to achieve these. " > > I'd like to delete this sentence, as I don't believe it's true in > these cases (unless one admits significantly inferior "solutions"). > And it's a statement that is damning enough to get an activity stopped. I feel no attachment to that sentence -- I'm guessing we were saying that other "more traditional" "solutions" would continue to be used (and in some cases, there exist actual solutions to the issue which _do_ serve the need.) > As previous editors of conex-concepts-uses, was there some history > behind including that sentence that I've missed? Toby is in a better position to say... -- John Leslie From john@jlc.net Mon Jul 11 17:33: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 B67D411E8158 for ; Mon, 11 Jul 2011 17:33:27 -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=[AWL=0.000, 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 Ljuc57xuxkJN for ; Mon, 11 Jul 2011 17:33:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B611E8110 for ; Mon, 11 Jul 2011 17:33:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3E83433C21; Mon, 11 Jul 2011 20:33:25 -0400 (EDT) Date: Mon, 11 Jul 2011 20:33:25 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110712003325.GC2822@verdi> References: <201107120021.p6C0LVhk018091@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107120021.p6C0LVhk018091@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] Fwd: New Version Notification - draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:33:27 -0000 Bob Briscoe wrote: > > We've posted a new -02 rev of conex-concepts-uses. Congratulations! (It's getting pretty late in the day for Bob...) >> http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-02.txt > > Main changes from draft-ietf-conex-concepts-uses-01 to -02: > > 1) Completely new Abstract & Introduction. I've spent some time on the Introduction, but don't feel able to comment without seeing how it fits the rest of the document. > 2) Concepts and Non-Goals sections added around existing slightly > altered definitions. My quick take is that the "blame" word is very dangerous -- I'll see if I can wordsmith around it. > 3) Clarifications to Existing Traffic Management section and > 4) Clarifications to Use-Cases section, with Other use Cases Added. > 5) Deployment Arrangements Section added (but only bulletted content > within it). These will have to wait until tomorrow -- or Wednesday, as I have some day-job responsibilities pending... > We had hoped to produce a document that at least had no {ToDo} > elements left in it, but it still needs another few hours work. Don't sweat that! Give it a few days' rest! -- John Leslie From toby@moncaster.com Mon Jul 11 23:00:51 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 C200B21F9169 for ; Mon, 11 Jul 2011 23:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 kXtxrJJ9Cnzj for ; Mon, 11 Jul 2011 23:00:51 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBE21F9168 for ; Mon, 11 Jul 2011 23:00:50 -0700 (PDT) Received: from [192.168.1.64] (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LvQBP-1Rf2ly3IJP-00zugJ; Tue, 12 Jul 2011 08:00:46 +0200 To: "=?utf-8?B?Sm9obiBMZXNsaWU=?=" , "=?utf-8?B?Qm9iIEJyaXNjb2U=?=" From: "=?utf-8?B?VG9ieSBNb25jYXN0ZXI=?=" Date: Tue, 12 Jul 2011 06:59:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1_1310450390666" Message-Id: <0LvQBP-1Rf2ly3IJP-00zugJ@mrelayeu.kundenserver.de> X-Provags-ID: V02:K0:QpQqMtocJVVyyAaeX+vxp6Fd3CLkc9rpz0ggDT6tB1a Qsf8CAJX4GND/DXO5C82gqLshrLtg5SysslP1dle8ecDj0841G jTb/NDrdi2f0NdNYMV8cnWgcBUZpWCTbbIlO6ye7VKfzcm6LLP 8ehgQlUZBPsF/wt4kqr6IPShNHNTCPcnzR6kZ02uBqLRA9w45/ moPZ7hOeQ/0E5hHfn+OidHth4+W+Zrdeb78FhaK0lU= Cc: =?utf-8?B?Q29uRXggSUVURiBsaXN0?= Subject: Re: [conex] =?utf-8?q?ConEx_is_not_the_only_solution=3F_conex-concept?= =?utf-8?q?s-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: Tue, 12 Jul 2011 06:00:51 -0000 ------=_Part_1_1310450390666 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBqb2huJ3MgcmlnaHQgYWJvdXQgd2h5IHRoYXQgc2VudGVuY2Ugd2FzIGluIHRoZXJl LiBJIGNlcnRhaW5seSBoYXZlIG5vIGF0dGFjaG1lbnQgdG8gaXQuCgpJJ2xsIHRyeSBhbmQgcmVh ZCB0aHJvdWdoIHRoZSBuZXcgdmVyc2lvbiBpbiB0aGUgbmV4dCBmZXcgZGF5cy4uLgoKVG9ieQoK U2VudCBmcm9tIG15IEhUQwoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiSm9obiBM ZXNsaWUiIDxqb2huQGpsYy5uZXQ+CkRhdGU6IFR1ZSwgSnVsIDEyLCAyMDExIDAxOjI2ClN1Ympl Y3Q6IFtjb25leF0gQ29uRXggaXMgbm90IHRoZSBvbmx5IHNvbHV0aW9uPyBjb25leC1jb25jZXB0 cy11c2VzClRvOiAiQm9iIEJyaXNjb2UiIDxib2IuYnJpc2NvZUBidC5jb20+CkNjOiAiQ29uRXgg SUVURiBsaXN0IiA8Y29uZXhAaWV0Zi5vcmc+CgoKQm9iIEJyaXNjb2UgPGJvYi5icmlzY29lQGJ0 LmNvbT4gd3JvdGU6Cj4gCj4gSm9obiwgVG9ieSwKPiAKPiBJbiB0aGUgaW50cm9kdWN0aW9uIHRv IHRoZSBtYWluIENvbkV4IHVzZSBjYXNlcyAoaW5mb3JtIHRyYWZmaWMgbWdtdCwgCj4gaW5jZW50 aXZpc2UgTEVEQkFUICYgaW50cmEtY2xhc3MgdXNlci1jb250cm9sbGVkIFFvUyksIGl0IGN1cnJl bnQgc2F5czoKPiAgICAgICAgICJJbiBtb3N0IGNhc2VzIENvbkV4IGlzIG5vdCB0aGUgb25seSBz b2x1dGlvbiB0byBhY2hpZXZlIHRoZXNlLiAiCj4gCj4gSSdkIGxpa2UgdG8gZGVsZXRlIHRoaXMg c2VudGVuY2UsIGFzIEkgZG9uJ3QgYmVsaWV2ZSBpdCdzIHRydWUgaW4gCj4gdGhlc2UgY2FzZXMg KHVubGVzcyBvbmUgYWRtaXRzIHNpZ25pZmljYW50bHkgaW5mZXJpb3IgInNvbHV0aW9ucyIpLiAK PiBBbmQgaXQncyBhIHN0YXRlbWVudCB0aGF0IGlzIGRhbW5pbmcgZW5vdWdoIHRvIGdldCBhbiBh Y3Rpdml0eSBzdG9wcGVkLgoKICAgSSBmZWVsIG5vIGF0dGFjaG1lbnQgdG8gdGhhdCBzZW50ZW5j ZSAtLSBJJ20gZ3Vlc3Npbmcgd2Ugd2VyZSBzYXlpbmcKdGhhdCBvdGhlciAibW9yZSB0cmFkaXRp b25hbCIgInNvbHV0aW9ucyIgd291bGQgY29udGludWUgdG8gYmUgdXNlZAooYW5kIGluIHNvbWUg Y2FzZXMsIHRoZXJlIGV4aXN0IGFjdHVhbCBzb2x1dGlvbnMgdG8gdGhlIGlzc3VlIHdoaWNoIF9k b18Kc2VydmUgdGhlIG5lZWQuKQoKPiBBcyBwcmV2aW91cyBlZGl0b3JzIG9mIGNvbmV4LWNvbmNl cHRzLXVzZXMsIHdhcyB0aGVyZSBzb21lIGhpc3RvcnkgCj4gYmVoaW5kIGluY2x1ZGluZyB0aGF0 IHNlbnRlbmNlIHRoYXQgSSd2ZSBtaXNzZWQ/CgogICBUb2J5IGlzIGluIGEgYmV0dGVyIHBvc2l0 aW9uIHRvIHNheS4uLgoKLS0KSm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldD4KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY29uZXggbWFpbGluZyBsaXN0CmNv bmV4QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29uZXgK ------=_Part_1_1310450390666 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayBqb2huJiMzOTtzIHJpZ2h0IGFib3V0IHdoeSB0aGF0IHNlbnRlbmNlIHdhcyBpbiB0 aGVyZS4gSSBjZXJ0YWlubHkgaGF2ZSBubyBhdHRhY2htZW50IHRvIGl0Ljxicj48YnI+SSYjMzk7 bGwgdHJ5IGFuZCByZWFkIHRocm91Z2ggdGhlIG5ldyB2ZXJzaW9uIGluIHRoZSBuZXh0IGZldyBk YXlzLi4uPGJyPjxicj5Ub2J5PGJyPjxicj5TZW50IGZyb20gbXkgSFRDPGJyPjxicj4tLS0tLSBS ZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90O0pvaG4gTGVzbGllJnF1b3Q7ICZsdDtq b2huQGpsYy5uZXQmZ3Q7PGJyPkRhdGU6IFR1ZSwgSnVsIDEyLCAyMDExIDAxOjI2PGJyPlN1Ympl Y3Q6IFtjb25leF0gQ29uRXggaXMgbm90IHRoZSBvbmx5IHNvbHV0aW9uPyBjb25leC1jb25jZXB0 cy11c2VzPGJyPlRvOiAmcXVvdDtCb2IgQnJpc2NvZSZxdW90OyAmbHQ7Ym9iLmJyaXNjb2VAYnQu Y29tJmd0Ozxicj5DYzogJnF1b3Q7Q29uRXggSUVURiBsaXN0JnF1b3Q7ICZsdDtjb25leEBpZXRm Lm9yZyZndDs8YnI+PGJyPjxicj5Cb2IgQnJpc2NvZSAmbHQ7Ym9iLmJyaXNjb2VAYnQuY29tJmd0 OyB3cm90ZTo8YnI+Jmd0OyA8YnI+Jmd0OyBKb2huLCBUb2J5LDxicj4mZ3Q7IDxicj4mZ3Q7IElu IHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIG1haW4gQ29uRXggdXNlIGNhc2VzIChpbmZvcm0gdHJh ZmZpYyBtZ210LCA8YnI+Jmd0OyBpbmNlbnRpdmlzZSBMRURCQVQgJmFtcDsgaW50cmEtY2xhc3Mg dXNlci1jb250cm9sbGVkIFFvUyksIGl0IGN1cnJlbnQgc2F5czo8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7SW4gbW9zdCBjYXNlcyBDb25FeCBpcyBub3QgdGhlIG9u bHkgc29sdXRpb24gdG8gYWNoaWV2ZSB0aGVzZS4gJnF1b3Q7PGJyPiZndDsgPGJyPiZndDsgSSYj Mzk7ZCBsaWtlIHRvIGRlbGV0ZSB0aGlzIHNlbnRlbmNlLCBhcyBJIGRvbiYjMzk7dCBiZWxpZXZl IGl0JiMzOTtzIHRydWUgaW4gPGJyPiZndDsgdGhlc2UgY2FzZXMgKHVubGVzcyBvbmUgYWRtaXRz IHNpZ25pZmljYW50bHkgaW5mZXJpb3IgJnF1b3Q7c29sdXRpb25zJnF1b3Q7KS4gPGJyPiZndDsg QW5kIGl0JiMzOTtzIGEgc3RhdGVtZW50IHRoYXQgaXMgZGFtbmluZyBlbm91Z2ggdG8gZ2V0IGFu IGFjdGl2aXR5IHN0b3BwZWQuPGJyPjxicj4gJm5ic3A7IEkgZmVlbCBubyBhdHRhY2htZW50IHRv IHRoYXQgc2VudGVuY2UgLS0gSSYjMzk7bSBndWVzc2luZyB3ZSB3ZXJlIHNheWluZzxicj50aGF0 IG90aGVyICZxdW90O21vcmUgdHJhZGl0aW9uYWwmcXVvdDsgJnF1b3Q7c29sdXRpb25zJnF1b3Q7 IHdvdWxkIGNvbnRpbnVlIHRvIGJlIHVzZWQ8YnI+KGFuZCBpbiBzb21lIGNhc2VzLCB0aGVyZSBl eGlzdCBhY3R1YWwgc29sdXRpb25zIHRvIHRoZSBpc3N1ZSB3aGljaCBfZG9fPGJyPnNlcnZlIHRo ZSBuZWVkLik8YnI+PGJyPiZndDsgQXMgcHJldmlvdXMgZWRpdG9ycyBvZiBjb25leC1jb25jZXB0 cy11c2VzLCB3YXMgdGhlcmUgc29tZSBoaXN0b3J5IDxicj4mZ3Q7IGJlaGluZCBpbmNsdWRpbmcg dGhhdCBzZW50ZW5jZSB0aGF0IEkmIzM5O3ZlIG1pc3NlZD88YnI+PGJyPiAmbmJzcDsgVG9ieSBp cyBpbiBhIGJldHRlciBwb3NpdGlvbiB0byBzYXkuLi48YnI+PGJyPi0tPGJyPkpvaG4gTGVzbGll ICZsdDtqb2huQGpsYy5uZXQmZ3Q7PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPmNvbmV4IG1haWxpbmcgbGlzdDxicj5jb25leEBpZXRmLm9yZzxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvbmV4Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvbmV4PC9hPjxicj48YnI+PGJy Pg== ------=_Part_1_1310450390666-- From toby@moncaster.com Tue Jul 12 02:36: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 89F7621F912C for ; Tue, 12 Jul 2011 02:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 aRXTAWl3pZsR for ; Tue, 12 Jul 2011 02:36:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7698A21F912A for ; Tue, 12 Jul 2011 02:36:25 -0700 (PDT) Received: from [10.0.10.88] (109-238-67-210.spitfireuk.net [109.238.67.210]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LlJ1m-1RFLuK1C9m-00bEB3; Tue, 12 Jul 2011 11:36:22 +0200 To: "=?utf-8?B?Qm9iIEJyaXNjb2U=?=" , "=?utf-8?B?Sm9obiBMZXNsaWU=?=" From: "=?utf-8?B?VG9ieSBNb25jYXN0ZXI=?=" Date: Tue, 12 Jul 2011 10:35:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2_1310463327467" Message-Id: <0LlJ1m-1RFLuK1C9m-00bEB3@mrelayeu.kundenserver.de> X-Provags-ID: V02:K0:lcOLZYSSEYsIKn/5INArGL6B/mxsmnc3n1huX+ca/mg t5gJ5894f10WH1goeXnhXRNi1N1I1o08WNsFOEglpI3YWRvjJQ nfFH7RkRxTZ55Wp/TwZ3LzufJIMe4TPflkq9ahC1zzXxGjTMRo D+zZEZ9OG/dIXWHQMzNWJNXXlZx0dHQh9vhuQRD+zDwFEshNJd tTdplbqtZcjQJQpn14/NvGObqEZwXBMQukwXNIvv9s= Cc: =?utf-8?B?Q29uRXggSUVURiBsaXN0?= Subject: Re: [conex] =?utf-8?q?ConEx_is_not_the_only_solution=3F_conex-concept?= =?utf-8?q?s-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: Tue, 12 Jul 2011 09:36:26 -0000 ------=_Part_2_1310463327467 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Sm9obiBjYXJlZnVsbHkgc2FpZCBzb2x1dGlvbnMgc2VydmUgdGhlIG5lZWQuIFRoYXQncyBhIGJp dCBkaWZmZXJlbnQgZnJvbSBzYXlpbmcgdGhleSBwZXJmZWN0bHkgYWRkcmVzcyB0aGUgQ29uZXgg dXNlIGNhc2VzLi4uIGJhc2ljYWxseSB0aGVyZSBhcmUgYnVzaW5lc3NlcyB0aGF0IHRoaW5rIHRo ZXkndmUgc29sdmVkIHRoaXMuIAoKU2VudCBmcm9tIG15IEhUQwoKLS0tLS0gUmVwbHkgbWVzc2Fn ZSAtLS0tLQpGcm9tOiAiQm9iIEJyaXNjb2UiIDxib2IuYnJpc2NvZUBidC5jb20+CkRhdGU6IFR1 ZSwgSnVsIDEyLCAyMDExIDA5OjQ1ClN1YmplY3Q6IFtjb25leF0gQ29uRXggaXMgbm90IHRoZSBv bmx5IHNvbHV0aW9uPyBjb25leC1jb25jZXB0cy11c2VzClRvOiAiVG9ieSBNb25jYXN0ZXIiIDx0 b2J5QG1vbmNhc3Rlci5jb20+LCAiSm9obiBMZXNsaWUiIDxqb2huQGpsYy5uZXQ+CkNjOiAiQ29u RXggSUVURiBsaXN0IiA8Y29uZXhAaWV0Zi5vcmc+CgoKVG9ieSwgSm9obiwKCldoaWNoIG90aGVy IHNvbHV0aW9ucyBkbyBhbnkgb2YgdGhlIHRocmVlIG1haW4gdXNlIGNhc2VzPwoKT25lIG9mIENv bWNhc3QncyBjb25jbHVzaW9ucyBmcm9tIGhhdmluZyBidWlsdCBmYWlyIHNoYXJlIHdhcyB0aGF0 IHRoZXNlIHdlcmUgdGhpbmdzIHRoZXkgY291bGRuJ3QgZG8gdG9kYXkuCgpTbyBpZiBhbnl0aGlu ZyB3ZSBzaG91bGQgYmUgc2F5aW5nIHRoZSBvcHBvc2l0ZSAtIHRoYXQgbm90aGluZyBlbHNlIGRv ZXMgdGhlc2UgdGhpbmdzIChhbmQgcmVmZXJyaW5nIHRvIENvbWNhc3QpLgoKVGhpcyBpcyBhbHNv IHRydWUgZm9yOgotICdwcmV2ZW50aW5nIGNvbmdlc3Rpb24gY29sbGFwc2UnIChvdGhlciB0aGFu IHZvbHVudGFyeSB1c2Ugb2YgY29uZ2VzdGlvbiBjb250cm9sKSBhbmQKLSBzZWVpbmcgaG93IG11 Y2ggY29uZ2VzdGlvbiBpcyBpbiB3aGljaCBvcGVyYXRvcidzIG5ldHdvcmsuCgpJbmZvcm1pbmcg cHJvdmlzaW9uaW5nIGlzIHRoZSBvbmx5IG9uZSB0aGF0IGNhbiBiZSBkb25lIG90aGVyIHdheXMg KGJ1dCB3aXRob3V0IGNvbmdlc3Rpb24tYmFzZWQgdHJhZmZpYyBtYW5hZ2VtZW50IGNvbmdlc3Rp b24gZG9lc24ndCBuZWNlc3NhcmlseSBtZWFuIHlvdSBjYW4ga25vdyB5b3UgKnNob3VsZCogdXBn cmFkZSBjYXBhY2l0eSkuCgoKQm9iCgpBdCAwNjo1OSAxMi8wNy8yMDExLCBUb2J5IE1vbmNhc3Rl ciB3cm90ZToKPkkgdGhpbmsgam9obidzIHJpZ2h0IGFib3V0IHdoeSB0aGF0IHNlbnRlbmNlIHdh cyBpbiB0aGVyZS4gSSA+Y2VydGFpbmx5IGhhdmUgbm8gYXR0YWNobWVudCB0byBpdC4KPgo+SSds bCB0cnkgYW5kIHJlYWQgdGhyb3VnaCB0aGUgbmV3IHZlcnNpb24gaW4gdGhlIG5leHQgZmV3IGRh eXMuLi4KPgo+VG9ieQo+Cj5TZW50IGZyb20gbXkgSFRDCj4KPi0tLS0tIFJlcGx5IG1lc3NhZ2Ug LS0tLS0KPkZyb206ICJKb2huIExlc2xpZSIgPGpvaG5AamxjLm5ldD4KPkRhdGU6IFR1ZSwgSnVs IDEyLCAyMDExIDAxOjI2Cj5TdWJqZWN0OiBbY29uZXhdIENvbkV4IGlzIG5vdCB0aGUgb25seSBz b2x1dGlvbj8gY29uZXgtY29uY2VwdHMtdXNlcwo+VG86ICJCb2IgQnJpc2NvZSIgPGJvYi5icmlz Y29lQGJ0LmNvbT4KPkNjOiAiQ29uRXggSUVURiBsaXN0IiA8Y29uZXhAaWV0Zi5vcmc+Cj4KPgo+ Qm9iIEJyaXNjb2UgPGJvYi5icmlzY29lQGJ0LmNvbT4gd3JvdGU6Cj4gPgo+ID4gSm9obiwgVG9i eSwKPiA+Cj4gPiBJbiB0aGUgaW50cm9kdWN0aW9uIHRvIHRoZSBtYWluIENvbkV4IHVzZSBjYXNl cyAoaW5mb3JtIHRyYWZmaWMgbWdtdCwKPiA+IGluY2VudGl2aXNlIExFREJBVCAmIGludHJhLWNs YXNzIHVzZXItY29udHJvbGxlZCBRb1MpLCBpdCBjdXJyZW50IHNheXM6Cj4gPiAgICAgICAgICJJ biBtb3N0IGNhc2VzIENvbkV4IGlzIG5vdCB0aGUgb25seSBzb2x1dGlvbiB0byBhY2hpZXZlIHRo ZXNlLiAiCj4gPgo+ID4gSSdkIGxpa2UgdG8gZGVsZXRlIHRoaXMgc2VudGVuY2UsIGFzIEkgZG9u J3QgYmVsaWV2ZSBpdCdzIHRydWUgaW4KPiA+IHRoZXNlIGNhc2VzICh1bmxlc3Mgb25lIGFkbWl0 cyBzaWduaWZpY2FudGx5IGluZmVyaW9yICJzb2x1dGlvbnMiKS4KPiA+IEFuZCBpdCdzIGEgc3Rh dGVtZW50IHRoYXQgaXMgZGFtbmluZyBlbm91Z2ggdG8gZ2V0IGFuIGFjdGl2aXR5IHN0b3BwZWQu Cj4KPiAgIEkgZmVlbCBubyBhdHRhY2htZW50IHRvIHRoYXQgc2VudGVuY2UgLS0gSSdtIGd1ZXNz aW5nIHdlIHdlcmUgc2F5aW5nCj50aGF0IG90aGVyICJtb3JlIHRyYWRpdGlvbmFsIiAic29sdXRp b25zIiB3b3VsZCBjb250aW51ZSB0byBiZSB1c2VkCj4oYW5kIGluIHNvbWUgY2FzZXMsIHRoZXJl IGV4aXN0IGFjdHVhbCBzb2x1dGlvbnMgdG8gdGhlIGlzc3VlIHdoaWNoIF9kb18KPnNlcnZlIHRo ZSBuZWVkLikKPgo+ID4gQXMgcHJldmlvdXMgZWRpdG9ycyBvZiBjb25leC1jb25jZXB0cy11c2Vz LCB3YXMgdGhlcmUgc29tZSBoaXN0b3J5Cj4gPiBiZWhpbmQgaW5jbHVkaW5nIHRoYXQgc2VudGVu Y2UgdGhhdCBJJ3ZlIG1pc3NlZD8KPgo+ICAgVG9ieSBpcyBpbiBhIGJldHRlciBwb3NpdGlvbiB0 byBzYXkuLi4KPgo+LS0KPkpvaG4gTGVzbGllIDxqb2huQGpsYy5uZXQ+Cg== ------=_Part_2_1310463327467 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Sm9obiBjYXJlZnVsbHkgc2FpZCBzb2x1dGlvbnMgc2VydmUgdGhlIG5lZWQuIFRoYXQmIzM5O3Mg YSBiaXQgZGlmZmVyZW50IGZyb20gc2F5aW5nIHRoZXkgcGVyZmVjdGx5IGFkZHJlc3MgdGhlIENv bmV4IHVzZSBjYXNlcy4uLiBiYXNpY2FsbHkgdGhlcmUgYXJlIGJ1c2luZXNzZXMgdGhhdCB0aGlu ayB0aGV5JiMzOTt2ZSBzb2x2ZWQgdGhpcy4gPGJyPjxicj5TZW50IGZyb20gbXkgSFRDPGJyPjxi cj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90O0JvYiBCcmlzY29lJnF1 b3Q7ICZsdDtib2IuYnJpc2NvZUBidC5jb20mZ3Q7PGJyPkRhdGU6IFR1ZSwgSnVsIDEyLCAyMDEx IDA5OjQ1PGJyPlN1YmplY3Q6IFtjb25leF0gQ29uRXggaXMgbm90IHRoZSBvbmx5IHNvbHV0aW9u PyBjb25leC1jb25jZXB0cy11c2VzPGJyPlRvOiAmcXVvdDtUb2J5IE1vbmNhc3RlciZxdW90OyAm bHQ7dG9ieUBtb25jYXN0ZXIuY29tJmd0OywgJnF1b3Q7Sm9obiBMZXNsaWUmcXVvdDsgJmx0O2pv aG5AamxjLm5ldCZndDs8YnI+Q2M6ICZxdW90O0NvbkV4IElFVEYgbGlzdCZxdW90OyAmbHQ7Y29u ZXhAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+VG9ieSwgSm9obiw8YnI+PGJyPldoaWNoIG90aGVy IHNvbHV0aW9ucyBkbyBhbnkgb2YgdGhlIHRocmVlIG1haW4gdXNlIGNhc2VzPzxicj48YnI+T25l IG9mIENvbWNhc3QmIzM5O3MgY29uY2x1c2lvbnMgZnJvbSBoYXZpbmcgYnVpbHQgZmFpciBzaGFy ZSB3YXMgdGhhdCB0aGVzZSB3ZXJlIHRoaW5ncyB0aGV5IGNvdWxkbiYjMzk7dCBkbyB0b2RheS48 YnI+PGJyPlNvIGlmIGFueXRoaW5nIHdlIHNob3VsZCBiZSBzYXlpbmcgdGhlIG9wcG9zaXRlIC0g dGhhdCBub3RoaW5nIGVsc2UgZG9lcyB0aGVzZSB0aGluZ3MgKGFuZCByZWZlcnJpbmcgdG8gQ29t Y2FzdCkuPGJyPjxicj5UaGlzIGlzIGFsc28gdHJ1ZSBmb3I6PGJyPi0gJiMzOTtwcmV2ZW50aW5n IGNvbmdlc3Rpb24gY29sbGFwc2UmIzM5OyAob3RoZXIgdGhhbiB2b2x1bnRhcnkgdXNlIG9mIGNv bmdlc3Rpb24gY29udHJvbCkgYW5kPGJyPi0gc2VlaW5nIGhvdyBtdWNoIGNvbmdlc3Rpb24gaXMg aW4gd2hpY2ggb3BlcmF0b3ImIzM5O3MgbmV0d29yay48YnI+PGJyPkluZm9ybWluZyBwcm92aXNp b25pbmcgaXMgdGhlIG9ubHkgb25lIHRoYXQgY2FuIGJlIGRvbmUgb3RoZXIgd2F5cyAoYnV0IHdp dGhvdXQgY29uZ2VzdGlvbi1iYXNlZCB0cmFmZmljIG1hbmFnZW1lbnQgY29uZ2VzdGlvbiBkb2Vz biYjMzk7dCBuZWNlc3NhcmlseSBtZWFuIHlvdSBjYW4ga25vdyB5b3UgKnNob3VsZCogdXBncmFk ZSBjYXBhY2l0eSkuPGJyPjxicj48YnI+Qm9iPGJyPjxicj5BdCAwNjo1OSAxMi8wNy8yMDExLCBU b2J5IE1vbmNhc3RlciB3cm90ZTo8YnI+Jmd0O0kgdGhpbmsgam9obiYjMzk7cyByaWdodCBhYm91 dCB3aHkgdGhhdCBzZW50ZW5jZSB3YXMgaW4gdGhlcmUuIEkgJmd0O2NlcnRhaW5seSBoYXZlIG5v IGF0dGFjaG1lbnQgdG8gaXQuPGJyPiZndDs8YnI+Jmd0O0kmIzM5O2xsIHRyeSBhbmQgcmVhZCB0 aHJvdWdoIHRoZSBuZXcgdmVyc2lvbiBpbiB0aGUgbmV4dCBmZXcgZGF5cy4uLjxicj4mZ3Q7PGJy PiZndDtUb2J5PGJyPiZndDs8YnI+Jmd0O1NlbnQgZnJvbSBteSBIVEM8YnI+Jmd0Ozxicj4mZ3Q7 LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4mZ3Q7RnJvbTogJnF1b3Q7Sm9obiBMZXNsaWUm cXVvdDsgJmx0O2pvaG5AamxjLm5ldCZndDs8YnI+Jmd0O0RhdGU6IFR1ZSwgSnVsIDEyLCAyMDEx IDAxOjI2PGJyPiZndDtTdWJqZWN0OiBbY29uZXhdIENvbkV4IGlzIG5vdCB0aGUgb25seSBzb2x1 dGlvbj8gY29uZXgtY29uY2VwdHMtdXNlczxicj4mZ3Q7VG86ICZxdW90O0JvYiBCcmlzY29lJnF1 b3Q7ICZsdDtib2IuYnJpc2NvZUBidC5jb20mZ3Q7PGJyPiZndDtDYzogJnF1b3Q7Q29uRXggSUVU RiBsaXN0JnF1b3Q7ICZsdDtjb25leEBpZXRmLm9yZyZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZn dDtCb2IgQnJpc2NvZSAmbHQ7Ym9iLmJyaXNjb2VAYnQuY29tJmd0OyB3cm90ZTo8YnI+Jmd0OyAm Z3Q7PGJyPiZndDsgJmd0OyBKb2huLCBUb2J5LDxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IElu IHRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIG1haW4gQ29uRXggdXNlIGNhc2VzIChpbmZvcm0gdHJh ZmZpYyBtZ210LDxicj4mZ3Q7ICZndDsgaW5jZW50aXZpc2UgTEVEQkFUICZhbXA7IGludHJhLWNs YXNzIHVzZXItY29udHJvbGxlZCBRb1MpLCBpdCBjdXJyZW50IHNheXM6PGJyPiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7SW4gbW9zdCBjYXNlcyBDb25FeCBpcyBu b3QgdGhlIG9ubHkgc29sdXRpb24gdG8gYWNoaWV2ZSB0aGVzZS4gJnF1b3Q7PGJyPiZndDsgJmd0 Ozxicj4mZ3Q7ICZndDsgSSYjMzk7ZCBsaWtlIHRvIGRlbGV0ZSB0aGlzIHNlbnRlbmNlLCBhcyBJ IGRvbiYjMzk7dCBiZWxpZXZlIGl0JiMzOTtzIHRydWUgaW48YnI+Jmd0OyAmZ3Q7IHRoZXNlIGNh c2VzICh1bmxlc3Mgb25lIGFkbWl0cyBzaWduaWZpY2FudGx5IGluZmVyaW9yICZxdW90O3NvbHV0 aW9ucyZxdW90OykuPGJyPiZndDsgJmd0OyBBbmQgaXQmIzM5O3MgYSBzdGF0ZW1lbnQgdGhhdCBp cyBkYW1uaW5nIGVub3VnaCB0byBnZXQgYW4gYWN0aXZpdHkgc3RvcHBlZC48YnI+Jmd0Ozxicj4m Z3Q7ICZuYnNwOyBJIGZlZWwgbm8gYXR0YWNobWVudCB0byB0aGF0IHNlbnRlbmNlIC0tIEkmIzM5 O20gZ3Vlc3Npbmcgd2Ugd2VyZSBzYXlpbmc8YnI+Jmd0O3RoYXQgb3RoZXIgJnF1b3Q7bW9yZSB0 cmFkaXRpb25hbCZxdW90OyAmcXVvdDtzb2x1dGlvbnMmcXVvdDsgd291bGQgY29udGludWUgdG8g YmUgdXNlZDxicj4mZ3Q7KGFuZCBpbiBzb21lIGNhc2VzLCB0aGVyZSBleGlzdCBhY3R1YWwgc29s dXRpb25zIHRvIHRoZSBpc3N1ZSB3aGljaCBfZG9fPGJyPiZndDtzZXJ2ZSB0aGUgbmVlZC4pPGJy PiZndDs8YnI+Jmd0OyAmZ3Q7IEFzIHByZXZpb3VzIGVkaXRvcnMgb2YgY29uZXgtY29uY2VwdHMt dXNlcywgd2FzIHRoZXJlIHNvbWUgaGlzdG9yeTxicj4mZ3Q7ICZndDsgYmVoaW5kIGluY2x1ZGlu ZyB0aGF0IHNlbnRlbmNlIHRoYXQgSSYjMzk7dmUgbWlzc2VkPzxicj4mZ3Q7PGJyPiZndDsgJm5i c3A7IFRvYnkgaXMgaW4gYSBiZXR0ZXIgcG9zaXRpb24gdG8gc2F5Li4uPGJyPiZndDs8YnI+Jmd0 Oy0tPGJyPiZndDtKb2huIExlc2xpZSAmbHQ7am9obkBqbGMubmV0Jmd0Ozxicj48YnI+PGJyPg== ------=_Part_2_1310463327467-- From Dirk.Kutscher@neclab.eu Tue Jul 12 03:14: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 2722921F8FD9 for ; Tue, 12 Jul 2011 03:14:21 -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 b4cGGAqJFDEK for ; Tue, 12 Jul 2011 03:14:20 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A03E921F8FD8 for ; Tue, 12 Jul 2011 03:14:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0104128000301 for ; Tue, 12 Jul 2011 12:14:20 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKs+EYNT-kLB for ; Tue, 12 Jul 2011 12:14:19 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D54FB28000174 for ; Tue, 12 Jul 2011 12:14:14 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 12:14:14 +0200 From: Dirk Kutscher To: ConEx IETF list Thread-Topic: update of Mobile Communication Congestion Exposure Scenario draft Thread-Index: AcxAfHIHYfHNf6sCQXS0ZU1eAnotLg== Date: Tue, 12 Jul 2011 10:14:13 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52491CC584FF@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [conex] update of Mobile Communication Congestion Exposure Scenario draft 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, 12 Jul 2011 10:14:21 -0000 Hi all, We have updated the Mobile Communication Congestion Exposure Scenario draft= : https://datatracker.ietf.org/doc/draft-kutscher-conex-mobile/ Thanks to all who provided comments -- we have tried to consider them all. Specifically this should now provide more information on how mobile communi= cation can benefit from congestion exposure. In addition to that, we have put a little more emphasis on how CONEX could = be employed incrementally and integrated with 3GPP's current PCC architectu= re. Any comment would be appreciated. Thanks, Dirk From bob.briscoe@bt.com Tue Jul 12 03:19: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 195B221F8FEC for ; Tue, 12 Jul 2011 03:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq98gjQSlgHR for ; Tue, 12 Jul 2011 03:19:17 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE121F8FEE for ; Tue, 12 Jul 2011 03:19:16 -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, 12 Jul 2011 09:45:51 +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, 12 Jul 2011 09:45:51 +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 131046034455; Tue, 12 Jul 2011 09:45:44 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.129.53]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6C8jl8l020025; Tue, 12 Jul 2011 09:45:48 +0100 Message-Id: <201107120845.p6C8jl8l020025@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jul 2011 09:45:44 +0100 To: Toby Moncaster , John Leslie From: Bob Briscoe In-Reply-To: <0LvQBP-1Rf2ly3IJP-00zugJ@mrelayeu.kundenserver.de> References: <0LvQBP-1Rf2ly3IJP-00zugJ@mrelayeu.kundenserver.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_664715530==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Jul 2011 08:45:51.0407 (UTC) FILETIME=[1A9F63F0:01CC4070] Cc: ConEx IETF list Subject: Re: [conex] ConEx is not the only solution? 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: Tue, 12 Jul 2011 10:19:18 -0000 --=====================_664715530==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Toby, John, Which other solutions do any of the three main use cases? One of Comcast's conclusions from having built fair share was that these were things they couldn't do today. So if anything we should be saying the opposite - that nothing else does these things (and referring to Comcast). This is also true for: - 'preventing congestion collapse' (other than voluntary use of congestion control) and - seeing how much congestion is in which operator's network. Informing provisioning is the only one that can be done other ways (but without congestion-based traffic management congestion doesn't necessarily mean you can know you *should* upgrade capacity). Bob At 06:59 12/07/2011, Toby Moncaster wrote: >I think john's right about why that sentence was in there. I >certainly have no attachment to it. > >I'll try and read through the new version in the next few days... > >Toby > >Sent from my HTC > >----- Reply message ----- >From: "John Leslie" >Date: Tue, Jul 12, 2011 01:26 >Subject: [conex] ConEx is not the only solution? conex-concepts-uses >To: "Bob Briscoe" >Cc: "ConEx IETF list" > > >Bob Briscoe wrote: > > > > John, Toby, > > > > In the introduction to the main ConEx use cases (inform traffic mgmt, > > incentivise LEDBAT & intra-class user-controlled QoS), it current says: > > "In most cases ConEx is not the only solution to achieve these. " > > > > I'd like to delete this sentence, as I don't believe it's true in > > these cases (unless one admits significantly inferior "solutions"). > > And it's a statement that is damning enough to get an activity stopped. > > I feel no attachment to that sentence -- I'm guessing we were saying >that other "more traditional" "solutions" would continue to be used >(and in some cases, there exist actual solutions to the issue which _do_ >serve the need.) > > > As previous editors of conex-concepts-uses, was there some history > > behind including that sentence that I've missed? > > Toby is in a better position to say... > >-- >John Leslie >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex > ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_664715530==.ALT Content-Type: text/html; charset="us-ascii" Toby, John,

Which other solutions do any of the three main use cases?

One of Comcast's conclusions from having built fair share was that these were things they couldn't do today.

So if anything we should be saying the opposite - that nothing else does these things (and referring to Comcast).

This is also true for:
- 'preventing congestion collapse' (other than voluntary use of congestion control) and
- seeing how much congestion is in which operator's network.

Informing provisioning is the only one that can be done other ways (but without congestion-based traffic management congestion doesn't necessarily mean you can know you *should* upgrade capacity).


Bob

At 06:59 12/07/2011, Toby Moncaster wrote:
I think john's right about why that sentence was in there. I certainly have no attachment to it.

I'll try and read through the new version in the next few days...

Toby

Sent from my HTC

----- Reply message -----
From: "John Leslie" <john@jlc.net>
Date: Tue, Jul 12, 2011 01:26
Subject: [conex] ConEx is not the only solution? conex-concepts-uses
To: "Bob Briscoe" <bob.briscoe@bt.com>
Cc: "ConEx IETF list" <conex@ietf.org>


Bob Briscoe <bob.briscoe@bt.com> wrote:
>
> John, Toby,
>
> In the introduction to the main ConEx use cases (inform traffic mgmt,
> incentivise LEDBAT & intra-class user-controlled QoS), it current says:
>         "In most cases ConEx is not the only solution to achieve these. "
>
> I'd like to delete this sentence, as I don't believe it's true in
> these cases (unless one admits significantly inferior "solutions").
> And it's a statement that is damning enough to get an activity stopped.

  I feel no attachment to that sentence -- I'm guessing we were saying
that other "more traditional" "solutions" would continue to be used
(and in some cases, there exist actual solutions to the issue which _do_
serve the need.)

> As previous editors of conex-concepts-uses, was there some history
> behind including that sentence that I've missed?

  Toby is in a better position to say...

--
John Leslie <john@jlc.net>
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_664715530==.ALT-- From swmike@swm.pp.se Tue Jul 12 03:24: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 123D421F9017 for ; Tue, 12 Jul 2011 03:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 qtyB7FfnkbMj for ; Tue, 12 Jul 2011 03:24:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABC21F9014 for ; Tue, 12 Jul 2011 03:24:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3309E1C1; Tue, 12 Jul 2011 12:24:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2F40A1C0 for ; Tue, 12 Jul 2011 12:24:20 +0200 (CEST) Date: Tue, 12 Jul 2011 12:24:20 +0200 (CEST) From: Mikael Abrahamsson To: conex@ietf.org In-Reply-To: <20110712000701.513.38329.idtracker@ietfa.amsl.com> Message-ID: References: <20110712000701.513.38329.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 10:24:23 -0000 On Mon, 11 Jul 2011, internet-drafts@ietf.org wrote: Hi, I have read this draft. Some comments. "Users are increasingly seeing congestion at peak times" This is not my reality. I would like to see this statement backed up by data. In my world congestion has decreased over time, not increased. Also, I don't agree with the whole philosphy and world-view of the text. Talking about "who causes congestion" just doesn't compute in my world, traffic is caused by two parties who want to communicate. Is the congestion caused by the web server sending the data packet or the user requesting the data packet from the web server? The text seems to want to blame congestion on someone, but I can't make out who of the two entities I just mentioned is to blame. Is it both? I also still don't understand congestion rate: "Conceptually, the instantaneous bit-rate of the traffic multiplied by the instantaneous congestion it is experiencing. What is the multiplier here, is it dependent on queue depth (ie increased delay), or is it a 0 or 1 depending on if it's being sent immediately or if there was a packet in the output buffer of the router? I don't understand the number that is created from the concept of "instananeous congestion" and how it's created. This also means I don't understand all the other congestion figures either. In my world either a link is congested or it isn't (well, a link is little congested a low queue depth and low drop rates, and more if either the drop rate or queue depth increase), and I don't understand how each flow can contribute more or less to this congestion, and how this can be determined. I think this is also the reason I don't understand the "ingress policer" and how it's supposed to work without understanding flows. In 5.1, there is talk about blocking traffic. What does this mean? Stop the flow completely by means of 100% packet loss? -- Mikael Abrahamsson email: swmike@swm.pp.se From bob.briscoe@bt.com Tue Jul 12 05:07: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 D646821F8FE5 for ; Tue, 12 Jul 2011 05:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 U8R47gKuOZnK for ; Tue, 12 Jul 2011 05:07:47 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id B6F7821F8FDC for ; Tue, 12 Jul 2011 05:07:46 -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); Tue, 12 Jul 2011 13:07:45 +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, 12 Jul 2011 13:07:45 +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 1310472456120; Tue, 12 Jul 2011 13:07:36 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.129.53]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6CC7fSG020823; Tue, 12 Jul 2011 13:07:42 +0100 Message-Id: <201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jul 2011 13:07:40 +0100 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: References: <20110712000701.513.38329.idtracker@ietfa.amsl.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: 12 Jul 2011 12:07:45.0342 (UTC) FILETIME=[4F172DE0:01CC408C] Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 12:07:48 -0000 Mike, This seems to be a mix of comments across two revisions. Are you sure all your comments apply to the -02 revision? We removed all the stuff in -01 about increasing congestion being a problem (as I said, congestion isn't a problem, it's a signal, and I agree, I would be very surprised if congestion is increasing in general). I removed the sentence in 5.1 about blocking too. I've searched -02 and I cannot find the phrases you're complaining about (so I'm pretty sure I didn't miss any occurrences). However, you clearly *have* read the -02 revision if you are concerned about the whole conceptual philosophy about blame, which was just added in -02. See inline, for responses on the blame stuff... At 11:24 12/07/2011, Mikael Abrahamsson wrote: >On Mon, 11 Jul 2011, internet-drafts@ietf.org wrote: > >Hi, I have read this draft. Some comments. > >"Users are increasingly seeing congestion at peak times" > >This is not my reality. I would like to see this statement backed up >by data. In my world congestion has decreased over time, not increased. No longer in -02 (or if it is, tell us where!) >Also, I don't agree with the whole philosphy and world-view of the text. >Talking about "who causes congestion" just doesn't compute in my >world, traffic is caused by two parties who want to communicate. Is >the congestion caused by the web server sending the data packet or >the user requesting the data packet from the web server? The text >seems to want to blame congestion on someone, but I can't make out >who of the two entities I just mentioned is to blame. Is it both? ConEx adds the ability to hold the sender (or sending network) responsible for contributing to congestion. That doesn't imply that holding the receiver responsible is wrong. Just insufficient. ConEx isn't saying you must hold the sender responsible, only that it must be possible to be able to, particularly because the sender is the one who is more fundamentally responsible for sending (see below). We already have the standards in place to expose congestion if we want to hold the receiver responsible (ie. ECN). At the IP layer, the sender is to blame for sending traffic. At the transport layer, the receiver is to blame for asking the sender to send. But in a packet network we get into all sorts of problems by conflating these two layers together and saying receivers cause packets to be sent to them. Ultimately: - senders can choose not to send content to whoever asks for it, - senders can choose not to send packets, - senders certainly can (and certainly do) choose how fast to send packets when they receive congestion feedback. THe draft does have text saying that either end can be held responsible (e.g. 5.1 discussed egress policing as well as ingress). But you are right that this needs explaining earlier, probably in the concepts section where blame is first discussed (or whatever word we end up using for it). >I also still don't understand congestion rate: > >"Conceptually, the instantaneous bit-rate of the traffic multiplied >by the instantaneous congestion it is experiencing. > >What is the multiplier here, is it dependent on queue depth (ie >increased delay), or is it a 0 or 1 depending on if it's being sent >immediately or if there was a packet in the output buffer of the >router? I don't understand the number that is created from the >concept of "instananeous congestion" and how it's created. This also >means I don't understand all the other congestion figures either. In >my world either a link is congested or it isn't (well, a link is >little congested a low queue depth and low drop rates, and more if >either the drop rate or queue depth increase), and I don't >understand how each flow can contribute more or less to this >congestion, and how this can be determined. I think this is also the >reason I don't understand the "ingress policer" and how it's >supposed to work without understanding flows. You're right that these definitions aren't helpful if you take the word "instantaneous" in its strict sense. You're right that instantaneous congestion for a particular packet is either 0 or 1. And similarly, the instantaneous bit-rate of one packet isn't a useful thing. Strictly the definition needs to say "the product of congestion and bit-rate over a short period that tends to instantaneous". The congestion-rate is just the time-varying rate at which bits are lost (either from a flow, a whole link, or whatever granularity you choose to measure it at). We just didn't want to call it the loss-rate for two reasons: - loss-rate is already sloppily used to mean the loss probability (in %). - congestion-rate generalises to loss and ECN. If you are sending at constant 10Mb/s through a queue of constant loss probability 0.1%, you will lose packets at 10kb/s, which is the congestion-rate of that flow. But the definition must allow for non-constant bit-rate and non-constant congestion. Because it can be very INcorrect to say that an average bit-rate of 10Mb/s through average congestion of 0.1% will lead to 10kb/s congestion-rate. A LEDBAT flow might achieve a much lower congestion-rate by sending rate peaks in congestion valleys and rate valleys in congestion peaks. >In 5.1, there is talk about blocking traffic. What does this mean? >Stop the flow completely by means of 100% packet loss? No longer in -02 (or if it is, tell us where!) Cheers Bob >-- >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Jul 12 09:29:37 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 C7A6821F8D54 for ; Tue, 12 Jul 2011 09:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 t6E-XFqV3Ezk for ; Tue, 12 Jul 2011 09:29:37 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0870121F8D4D for ; Tue, 12 Jul 2011 09:29:36 -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, 12 Jul 2011 17:29:35 +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, 12 Jul 2011 17:29:35 +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 1310488163643; Tue, 12 Jul 2011 17:29:23 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.190]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6CGTVe2021643; Tue, 12 Jul 2011 17:29:32 +0100 Message-Id: <201107121629.p6CGTVe2021643@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jul 2011 17:29:26 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <0LlJ1m-1RFLuK1C9m-00bEB3@mrelayeu.kundenserver.de> References: <0LlJ1m-1RFLuK1C9m-00bEB3@mrelayeu.kundenserver.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: 12 Jul 2011 16:29:35.0505 (UTC) FILETIME=[E313D010:01CC40B0] Cc: ConEx IETF list Subject: Re: [conex] ConEx is not the only solution? 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: Tue, 12 Jul 2011 16:29:37 -0000 Toby, What I'm fishing for is examples of things that can do each use-case. I don't mean can do well, I mean can do at all. Bob At 10:35 12/07/2011, Toby Moncaster wrote: >John carefully said solutions serve the need. That's a bit different >from saying they perfectly address the Conex use cases... basically >there are businesses that think they've solved this. > >Sent from my HTC > >----- Reply message ----- >From: "Bob Briscoe" >Date: Tue, Jul 12, 2011 09:45 >Subject: [conex] ConEx is not the only solution? conex-concepts-uses >To: "Toby Moncaster" , "John Leslie" >Cc: "ConEx IETF list" > > >Toby, John, > >Which other solutions do any of the three main use cases? > >One of Comcast's conclusions from having built fair share was that >these were things they couldn't do today. > >So if anything we should be saying the opposite - that nothing else >does these things (and referring to Comcast). > >This is also true for: >- 'preventing congestion collapse' (other than voluntary use of >congestion control) and >- seeing how much congestion is in which operator's network. > >Informing provisioning is the only one that can be done other ways >(but without congestion-based traffic management congestion doesn't >necessarily mean you can know you *should* upgrade capacity). > > >Bob > >At 06:59 12/07/2011, Toby Moncaster wrote: > >I think john's right about why that sentence was in there. > I >certainly have no attachment to it. > > > >I'll try and read through the new version in the next few days... > > > >Toby > > > >Sent from my HTC > > > >----- Reply message ----- > >From: "John Leslie" > >Date: Tue, Jul 12, 2011 01:26 > >Subject: [conex] ConEx is not the only solution? conex-concepts-uses > >To: "Bob Briscoe" > >Cc: "ConEx IETF list" > > > > > >Bob Briscoe wrote: > > > > > > John, Toby, > > > > > > In the introduction to the main ConEx use cases (inform traffic mgmt, > > > incentivise LEDBAT & intra-class user-controlled QoS), it current says: > > > "In most cases ConEx is not the only solution to achieve these. " > > > > > > I'd like to delete this sentence, as I don't believe it's true in > > > these cases (unless one admits significantly inferior "solutions"). > > > And it's a statement that is damning enough to get an activity stopped. > > > > I feel no attachment to that sentence -- I'm guessing we were saying > >that other "more traditional" "solutions" would continue to be used > >(and in some cases, there exist actual solutions to the issue which _do_ > >serve the need.) > > > > > As previous editors of conex-concepts-uses, was there some history > > > behind including that sentence that I've missed? > > > > Toby is in a better position to say... > > > >-- > >John Leslie > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From swmike@swm.pp.se Tue Jul 12 22:55: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 11E8721F8B92 for ; Tue, 12 Jul 2011 22:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 SwXqH3DjL-Eg for ; Tue, 12 Jul 2011 22:55:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3482821F8B7E for ; Tue, 12 Jul 2011 22:55:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E82752A1; Wed, 13 Jul 2011 07:54:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E4E152A0; Wed, 13 Jul 2011 07:54:59 +0200 (CEST) Date: Wed, 13 Jul 2011 07:54:59 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk> Message-ID: References: <20110712000701.513.38329.idtracker@ietfa.amsl.com> <201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 05:55:02 -0000 On Tue, 12 Jul 2011, Bob Briscoe wrote: > Are you sure all your comments apply to the -02 revision? I opened a lot of documents and tabs yesterday to read up on all published documents in CONEX, I probably indeed have messed up and had multiple revisions. So, now re-reading which I hope is correct. I'll take your reply in consideration and start anew on my comments: So, congestion volume description starts to make sense, for me as a router guy this now is "any packet that couldn't be sent immediately (or within a very low buffer threshold value) or which was over the rate a policer was configured to. This, however, is NOT ECN marking , so basically to interoperate with non-ECN traffic, there needs to be a new flag (or one needs to start marking/dropping (if it's ECN enabled packet or not) very early in the queue depth). Just to make an example, I would like to have end systems consider a link congested as soon as a packet was buffered more than 1ms, that doesn't mean I want to start dropping non-ECN packet at that level, so what do we do? With the current scheme, if I have a WRED profile that starts marking/dropping at 30ms queue depth, I'd consider this quite heavily congested before the current scheme would do so. So how should operators configure their AQM to work best in a conex world? I also imagine it should be different depending on link speed and amount of users sharing that link (ie a 100GE core link should have different AQM from a 10 meg user access line). I believe recommendations in this area are needed. In section 4 this is discussed, and for LEDBAT to work, there needs to be some buffering before TCP starts to consider the link congested, but LEDBAT would notice it before. How is this signalled, is LEDBAT just simply more sensitive to delay variations and back off its rate a lot more aggressively? Coming back to "instantaneous", I'd still like this defined a bit more, I guess we're talking second scale resolution here, or perhaps minutes? Apart from that I think I read -01 revision, because most of the things I responded to earlier didn't exist in -02. -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Wed Jul 13 09:33: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 86F5121F8642 for ; Wed, 13 Jul 2011 09:33:16 -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=[AWL=0.000, 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 opjWCj35TUjM for ; Wed, 13 Jul 2011 09:33:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1084C11E816E for ; Wed, 13 Jul 2011 09:33:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8E36C33C20; Wed, 13 Jul 2011 12:33:14 -0400 (EDT) Date: Wed, 13 Jul 2011 12:33:14 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110713163314.GE2822@verdi> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Wed, 13 Jul 2011 16:33:16 -0000 Bob Briscoe wrote: > > Please give feedback on the proposed new Concepts text below that > precedes the definitions. > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > 2. Concepts > > Despite its central role in network control and management, > congestion is a remarkably hard concept to define. [Bauer09] > provides a good academic background. For the purposes of ConEx, the > definition below focuses on how congestion would be measured, rather > than precisely what it is. Our definition of congestion is then > equivalent to the loss probability (or the marking probability if ECN > is used). Seems good... > ConEx is essentially about accountability for congestion (or blame in > crude language). The blame for congestion lies equally between too > little capacity and too much traffic. On the capacity side, > congestion itself measures how badly the network provider is to > blame. On the traffic side, in a shared network, the blame is split > among all the users. Congestion-volume measures how much of each > user's traffic is to blame for the congestion. Note that congestion- > volume is a property of traffic, whereas congestion is a property of > a link or a path. "Blame" is a bad paradigm: once it is introduced, it's hard to avoid degenerating into arguments of where "blame" belongs. We have up to now tried to avoid such distractions. Thus, I attempt some wordsmithing: " " Congestion is a signal that sender(s) and/or receiver(s) may (or may " not) be willing to bear a share of the cost of upgrading a congested " link. But without accountability, the network operator can't quantify " that willingness. Blaming the network operator is easy, but moot; " blaming the sender is harder, because you can't tell which sender to " blame. " " With ConEx accountability, you can quantify which senders intentionally " sent data over a path known to be congested. While ConEx doesn't " consider how to assess cost, it does ensure that the needed information " is right there in the IP packet. Even without any mechanism to assess " cost, this information better informs any judgment of when to upgrade. > Congestion-volume is a relatively newly defined metric that is > central to ConEx. To grasp an intuitive feel for what congestion- > volume measures, some network operators give you an allowance and > only count data volume during the peak period against it. This is > equivalent to counting your congestion-volume by assuming that > congestion is 100% during the peak period and 0% otherwise. This is hard to read. Some possible wordsmithing: " " Congestion-volume is a property of traffic central to ConEx. Some " network operators already do a crude approximation by giving their " customers a volume allowance during "peak usage". This can be " thought of as assuming 100% congestion during peak and 0% otherwise. " We refine that by counting only packets during actual congestion: " thus assuming 100% congestion for packets marked or dropped, and " 0% for packets neither marked nor dropped (though in practice we " need to count packets marked for Congestion-Expected, which lags " the actual congestion by one Round-Trip-Time). > The congestion-volume metric is more refined but broadly equivalent, > and still as simple to measure as the above time-of-day volume. > Imagine Alice sends 1GB while the loss-probability is a constant > 0.2%. Then her contribution to congestion (or congestion-volume) is > 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is 0.1%, > this adds 3MB to her congestion-volume. Her total contribution to > congestion is then 2MB+3MB = 5MB. > > To measure Alice's congestion-volume no-one has to do all these > multiplications and additions. It is simply a matter of counting the > total volume of Alice's traffic that was discarded (a queue with a > percentage loss involves multiplication inherently). I don't think these two paragraphs are needed (but I'm not objecting to them -- merely suggesting how to get to the point before losing our readers). > Finally, there is yet another way to cut the blame for congestion. > Recall that the level of congestion itself measures the provider's > blame. However, in an internetwork there are multiple providers. If > a data centre network with zero congestion is connected to an access > network and sends traffic over a link with 0.4% loss probability, > then clearly all the blame for congestion lies with the access > network. However, at another time, there might be 0.1% congestion > across the data centre and 0.7% across the access, making 0.8% end- > to-end congestion across the path. I do object to this paragraph. I don't believe it's needed, and I can see no way to wordsmith it to avoid the "blame" game. > In order to apportion blame accordingly, ConEx is designed so that a > meter at the border can see how much of the congestion is on one side > or other, termed upstream and downstream congestion. Here a simple s/apportion blame accordingly/establish accountability/ should suffice. > If A and B are connected within a chain of more than two networks, A > attributes all congestion beyond B to B, and vice versa. As far as A > is concerned, B chooses who to route to, so B takes responsibility > for its choices. I could probably improve on this, but I'm not going to try right now. > 2.1. Definitions > > Congestion: Congestion occurs when any user's traffic suffers > increased delay, loss or ECN marking as a result of one or more > network resources becoming overloaded. For the purposes of ConEx, > the focus is on concrete signals of congestion (ECN and loss), > therefore delay is set to one side. Congestion is measured as the > probability of loss or the probability of ECN marking, usually > expressed as dimensionless percentages. I find "delay is set to one side" confusing: I think it would be better to say "delay is not considered". Also, I find the "Congestion is measured as" sentence a bit misleading. ConEx actually is about including a Congestion-Expected signal: exactly how the sender measures the congestion expected is out-of scope. Perhaps: " " Congestion is the probability of loss and/or ECN marking, expressed " as a dimensionless fraction. > Congestion-volume: For any granularity of traffic (packet, flow, > aggregate, link, etc.), the volume of bytes dropped or marked in a > given period of time. Conceptually, data volume multiplied by the > instantaneous congestion each packet of the volume experienced. > Usually expressed in bytes (or MB, GB, of course). Nit: s/Conceptually, data volume/Conceptually it is data volume/ > Congestion-rate: For any granularity of traffic (packet, flow, > aggregate, link, etc.), the instantaneous rate of traffic > discarded or marked due to congestion. Conceptually, the > instantaneous bit-rate of the traffic weighted by the > instantaneous congestion it experiences. Usually expressed in > b/s. This is confusing, and the term isn't used in the document. I suggest removing the definition. (Otherwise, we need to see how it will be used and make sure we understand that concept before wordsmithing.) > Upstream Congestion: The accumulated level of congestion experienced > by a traffic flow thus far, relative to a point along its path. > In other words, at any point the Upstream Congestion is the > accmulated level of congestion the traffic flow has experienced as > it travels from the sender to that point. At the receiver this is > equivalent to the end-to-end congestion level that (usually) is > reported back to the sender. > > Downstream Congestion: The level of congestion a flow of traffic is > expected to experience on the remainder of its path. In other > words, at any point the Downstream Congestion is the level of > congestion the traffic flow is yet to experience as it travels > from that point to the receiver. Aka. Rest-of-Path Congestion. > > Consumer: A general term representing the contractual entity such as > a user or business or institution that uses the service of a > network provider. There is no implication that the contract has > to be commercial; for instance the consumers of a University or > enterprise network service would be students or employees and they > might well be required to comply with some form of contract or > acceptable use policy. There is also no implication that the > consumer is necessarily an end-consumer. Where two networks form > a customer-provider relationship, the term consumer is also > intended to cover the customer network. Personally, I would prefer "customer" to "consumer". "Consumer" suggests we're talking about the receiver as opposed to the sender. > Network provider: (also 'operator'): the term is not confined to > Internet service providers (ISPs) who run commercial public > networks but is also intended to generalise to operators of > enterprise, campus and other networks. > > [ConEx-Abstract-Mech] gives further definitions for aspects of ConEx > to do with protocol mechanisms. I'm not sure quite what this means: does it imply that we need to read abstract-mech for definitions used in this document? (I would prefer we not ask our readers to do that.) -- John Leslie From bob.briscoe@bt.com Wed Jul 13 09:50: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 2094711E819E for ; Wed, 13 Jul 2011 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 A0FNY5wZ1MX2 for ; Wed, 13 Jul 2011 09:50:11 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id CE58411E819B for ; Wed, 13 Jul 2011 09:50:10 -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); Wed, 13 Jul 2011 17:50:09 +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); Wed, 13 Jul 2011 17:50:09 +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 1310575804297; Wed, 13 Jul 2011 17:50:04 +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 p6DGo4mG026334; Wed, 13 Jul 2011 17:50:04 +0100 Message-Id: <201107131650.p6DGo4mG026334@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jul 2011 17:50:05 +0100 To: , From: Bob Briscoe In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.doma in1.systemhost.net> References: <201107071925.p67JPZY0027277@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2DE4448@EMV65-UKRD.domain1.systemhost.net> 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: 13 Jul 2011 16:50:09.0187 (UTC) FILETIME=[ECD27F30:01CC417C] Cc: conex@ietf.org Subject: Re: [conex] Non-goals and/or misconceptions for 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: Wed, 13 Jul 2011 16:50:12 -0000 Phil, Georgios, At 16:14 09/07/2011, philip.eardley@bt.com wrote: >Conex enables IP nodes to see information about the whole path >congestion, so that it is visible as a useful metric; for example to >inform the operator's traffic management. > >In order to achieve this, the sender signals the information at the >transport layer. >The WG is chartered to define this signalling for the TCP transport. >It would clearly be possible to also define this signalling for >non-TCP transports ... and in our original re-ECN drafts we gave guidelines on how to do this for DCCP, SCTP, NSIS/RSVP and the various main styles of UDP transport - it really isn't difficult. Bob >phil > >________________________________________ >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of >Georgios Karagiannis [karagian@cs.utwente.nl] >Sent: 09 July 2011 07:18 >To: Briscoe,RJ,Bob,DES8 R >Cc: conex@ietf.org >Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-uses > >Hi Bob, > >The text looks good, but I have one comment associated with the following >paragraph: > > > Capacity provisioning in relation to ConEx is another area of > > confusion. Congestion-based traffic management is not an alternative > > to good capacity provisioning. Either or both can be good practice > > depending on the situation, and ConEx can provide a useful metric for > > both (see Section 5.4). > > >Will the features provided Connex apply only to applications that are >using TCP as a transport protocol? >In other words, will the Conex useful metric, mentioned in the paragraph >above, be used by capacity provisioning and congestion-based traffic >management only for applcations that are using TCP as transport protocol >(and not for applications that are using a non-TCP transport protocol)? > >If the answer is yes, then please see below: > > >Consider now that there are applications that use a non-TCP protocol, >e.g., DCCP, that are generating a lot of traffic and are the main causes >of congestion in the network. > >Since the capacity provisioning and congestion-based traffic management >will not be able to use the Conex metrics, then the behaviour of the >non-TCP applications that are generating the congestion cannot be >effectively "controled" by using the augmented features provided by >Conex. >In this case for these non-TCP based applications only the current means >of providing congestion control and capacity provisioning can be used. > >It might also mean that only the applications that are using TCP as >transport protocol will be effectively "controlled", while they >should'nt. > >Best regards, >Georgios > > > >On 7/7/2011, "Bob Briscoe" wrote: > > >Phil & all, > > > >I've decided the question & answer style broke up the flow. So here > >it is re-written in prose and much shorter cos I've cut out chunks > >that weren't really nec (e.g. utilisation != congestion)... > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > >2.2. Non-Goals of ConEx and Common Misconceptions > > > > Congestion exposure is about the transport sender exposing congestion > > to the network, not the other way round. That would not make sense > > given by design the transport endpoints handle congestion in the > > TCP/IP protocol suite. > > > > Nonetheless, it is a non-goal for IP layer devices to use this ConEx > > information to do fine-grained congestion control. That is still > > best done at the transport sender. There is also no expectation that > > the information will be used by every IP router and forwarding > > device. More likely, specific ConEx-based functions like traffic > > management will be added to edge routers. This in turn should > > incentivize end-system transports to be more careful about congesting > > others. > > > > Note that good behaviour at individual flow granularity is the > > intended outcome, not the forcing function--it is the end, not the > > means. Enforcing per-flow compliance to the TCP congestion response > > (or any per-flow rate enforcement) is a non-goal: > > > > o It used to be commonly believed that TCP-friendliness was critical > > to fairness on the Internet. However, a particular congestion > > control algorithm doesn't determine how much data an application > > transfers, or how many flows it opens, or which congestion control > > algorithm an application uses, or how many applications the user > > runs, or how many users are active at once. These factors all > > have a stronger impact on how great a share of a link is available > > for any particular data transfer. To achieve fairness at this > > broader granularity (between users, homes, sites or whole > > networks) requires that individual flows in the same bottleneck > > will sometimes be very unequal. > > > > o If the network forced everything to be TCP-friendly, some > > important applications would not work. Worse still, this would > > prevent deployment of higher performance replacements to TCP. It > > is important to allow give and take between one user's flows: some > > > > > > > >Briscoe & Woundy Expires January 5, 2012 [Page 7] > > > >Internet-Draft ConEx Mechanism July 2011 > > > > > > can be more aggressive than TCP and others less, e.g. long > > transfers, following the example of LEDBAT [LEDBAT] (see > > Section 5.2). > > > > Therefore, network enforcement of per-flow fairness is not only a > > non-goal, it would be a harmful goal in many respects. > > > > Capacity provisioning in relation to ConEx is another area of > > confusion. Congestion-based traffic management is not an alternative > > to good capacity provisioning. Either or both can be good practice > > depending on the situation, and ConEx can provide a useful metric for > > both (see Section 5.4). > > > > However, removing congestion from _all_ parts of a network is > > unlikely to be a goal. If an end-to-end transport protocol cannot go > > fast enough to cause congestion somewhere along the path, it is > > probably broken. A good transport protocol will continue to > > accelerate until it encounters a bottleneck--typically in an access > > network (or all too often in the receiver's buffer, but that's > > another story). Low levels of congestion _somewhere_ are therefore > > healthy. Just to be clear though, zero congestion somewhere (e.g. the > > core) is also perfectly healthy. > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > > > > >At 13:34 07/07/2011, philip.eardley@bt.com wrote: > >>Your suggestions look good. > >>Personally would put them later. A good, simple explanation of what > >>conex is about should reduce the chances of a reader being > >>misconceived. You could always put an advert early in the doc > >> > >>Cong & utilisation - would make this a question in its own right. > >>I'd expand it a bit. Explain how acting assuming it's one (& in fact > >>it's the other) leads to wrong 'cures'. > >> > >>Network traffic mgt does congestion control? - the bullet could be > >>clearer. TM can be on just as fast timescales as cong control. the > >>"arbitrate overall fairness" point is only one possibility for how > >>TM can use conex info (& the next bullet explains that case) > >> > >>I'm not sure the first question is quite right, but am not inspired > >>with an alternative at the moment > >> > >> > >>-----Original Message----- > > > >________________________________________________________________ > >Bob Briscoe, BT Innovate & Design > > > >_______________________________________________ > >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 karagian@cs.utwente.nl Wed Jul 13 10:13: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 9B80B21F8A51 for ; Wed, 13 Jul 2011 10:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6, 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 DkZOZN3In++A for ; Wed, 13 Jul 2011 10:13:55 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5470621F876F for ; Wed, 13 Jul 2011 10:13:55 -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 p6DHC9Y5000586; Wed, 13 Jul 2011 19:12:09 +0200 (MEST) Received: from 130.89.12.129 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 13 Jul 2011 17:13:58 +0000 To: "Bob Briscoe" , "philip.eardley@bt.com" Date: Wed, 13 Jul 2011 17:13:58 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201107131650.p6DGo4mG026334@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]); Wed, 13 Jul 2011 19:12:19 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] Non-goals and/or misconceptions for 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: Wed, 13 Jul 2011 17:13:56 -0000 Hi Bob, Section 6.2 gives guidelines on which changes (e.g.,add an additional ECC object) need to be done in the existing non-TCP transport protocols. It is important to investigate whether there are ways of using these non-TCP protocols without requiring any protocol changes to them (requiring to add an object)! Best regards, Georgios On 7/13/2011, "Bob Briscoe" wrote: >Phil, Georgios, > >At 16:14 09/07/2011, philip.eardley@bt.com wrote: >>Conex enables IP nodes to see information about the whole path >>congestion, so that it is visible as a useful metric; for example to >>inform the operator's traffic management. >> >>In order to achieve this, the sender signals the information at the >>transport layer. >>The WG is chartered to define this signalling for the TCP transport. >>It would clearly be possible to also define this signalling for >>non-TCP transports > >... and in our original re-ECN drafts we gave guidelines on how to do >this for DCCP, SCTP, NSIS/RSVP and the various main styles of UDP >transport - it really isn't difficult. > > > > > >Bob > > >>phil >> >>________________________________________ >>From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of >>Georgios Karagiannis [karagian@cs.utwente.nl] >>Sent: 09 July 2011 07:18 >>To: Briscoe,RJ,Bob,DES8 R >>Cc: conex@ietf.org >>Subject: Re: [conex] Non-goals and/or misconceptions for conex-concepts-use= s >> >>Hi Bob, >> >>The text looks good, but I have one comment associated with the following >>paragraph: >> >> > Capacity provisioning in relation to ConEx is another area of >> > confusion. Congestion-based traffic management is not an alternative >> > to good capacity provisioning. Either or both can be good practice >> > depending on the situation, and ConEx can provide a useful metric for >> > both (see Section 5.4). >> >> >>Will the features provided Connex apply only to applications that are >>using TCP as a transport protocol? >>In other words, will the Conex useful metric, mentioned in the paragraph >>above, be used by capacity provisioning and congestion-based traffic >>management only for applcations that are using TCP as transport protocol >>(and not for applications that are using a non-TCP transport protocol)? >> >>If the answer is yes, then please see below: >> >> >>Consider now that there are applications that use a non-TCP protocol, >>e.g., DCCP, that are generating a lot of traffic and are the main causes >>of congestion in the network. >> >>Since the capacity provisioning and congestion-based traffic management >>will not be able to use the Conex metrics, then the behaviour of the >>non-TCP applications that are generating the congestion cannot be >>effectively "controled" by using the augmented features provided by >>Conex. >>In this case for these non-TCP based applications only the current means >>of providing congestion control and capacity provisioning can be used. >> >>It might also mean that only the applications that are using TCP as >>transport protocol will be effectively "controlled", while they >>should'nt. >> >>Best regards, >>Georgios >> >> >> >>On 7/7/2011, "Bob Briscoe" wrote: >> >> >Phil & all, >> > >> >I've decided the question & answer style broke up the flow. So here >> >it is re-written in prose and much shorter cos I've cut out chunks >> >that weren't really nec (e.g. utilisation !=3D congestion)... >> > >> >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> >2.2. Non-Goals of ConEx and Common Misconceptions >> > >> > Congestion exposure is about the transport sender exposing congestion >> > to the network, not the other way round. That would not make sense >> > given by design the transport endpoints handle congestion in the >> > TCP/IP protocol suite. >> > >> > Nonetheless, it is a non-goal for IP layer devices to use this ConEx >> > information to do fine-grained congestion control. That is still >> > best done at the transport sender. There is also no expectation that >> > the information will be used by every IP router and forwarding >> > device. More likely, specific ConEx-based functions like traffic >> > management will be added to edge routers. This in turn should >> > incentivize end-system transports to be more careful about congesting >> > others. >> > >> > Note that good behaviour at individual flow granularity is the >> > intended outcome, not the forcing function--it is the end, not the >> > means. Enforcing per-flow compliance to the TCP congestion response >> > (or any per-flow rate enforcement) is a non-goal: >> > >> > o It used to be commonly believed that TCP-friendliness was critical >> > to fairness on the Internet. However, a particular congestion >> > control algorithm doesn't determine how much data an application >> > transfers, or how many flows it opens, or which congestion control >> > algorithm an application uses, or how many applications the user >> > runs, or how many users are active at once. These factors all >> > have a stronger impact on how great a share of a link is available >> > for any particular data transfer. To achieve fairness at this >> > broader granularity (between users, homes, sites or whole >> > networks) requires that individual flows in the same bottleneck >> > will sometimes be very unequal. >> > >> > o If the network forced everything to be TCP-friendly, some >> > important applications would not work. Worse still, this would >> > prevent deployment of higher performance replacements to TCP. It >> > is important to allow give and take between one user's flows: some >> > >> > >> > >> >Briscoe & Woundy Expires January 5, 2012 [Page 7] >> > >> >Internet-Draft ConEx Mechanism July 2011 >> > >> > >> > can be more aggressive than TCP and others less, e.g. long >> > transfers, following the example of LEDBAT [LEDBAT] (see >> > Section 5.2). >> > >> > Therefore, network enforcement of per-flow fairness is not only a >> > non-goal, it would be a harmful goal in many respects. >> > >> > Capacity provisioning in relation to ConEx is another area of >> > confusion. Congestion-based traffic management is not an alternative >> > to good capacity provisioning. Either or both can be good practice >> > depending on the situation, and ConEx can provide a useful metric for >> > both (see Section 5.4). >> > >> > However, removing congestion from _all_ parts of a network is >> > unlikely to be a goal. If an end-to-end transport protocol cannot go >> > fast enough to cause congestion somewhere along the path, it is >> > probably broken. A good transport protocol will continue to >> > accelerate until it encounters a bottleneck--typically in an access >> > network (or all too often in the receiver's buffer, but that's >> > another story). Low levels of congestion _somewhere_ are therefore >> > healthy. Just to be clear though, zero congestion somewhere (e.g. th= e >> > core) is also perfectly healthy. >> >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >> > >> > >> > >> >At 13:34 07/07/2011, philip.eardley@bt.com wrote: >> >>Your suggestions look good. >> >>Personally would put them later. A good, simple explanation of what >> >>conex is about should reduce the chances of a reader being >> >>misconceived. You could always put an advert early in the doc >> >> >> >>Cong & utilisation - would make this a question in its own right. >> >>I'd expand it a bit. Explain how acting assuming it's one (& in fact >> >>it's the other) leads to wrong 'cures'. >> >> >> >>Network traffic mgt does congestion control? - the bullet could be >> >>clearer. TM can be on just as fast timescales as cong control. the >> >>"arbitrate overall fairness" point is only one possibility for how >> >>TM can use conex info (& the next bullet explains that case) >> >> >> >>I'm not sure the first question is quite right, but am not inspired >> >>with an alternative at the moment >> >> >> >> >> >>-----Original Message----- >> > >> >________________________________________________________________ >> >Bob Briscoe, BT Innovate & Design >> > >> >_______________________________________________ >> >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 Dirk.Kutscher@neclab.eu Thu Jul 14 02:27:14 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 310DD21F8726 for ; Thu, 14 Jul 2011 02:27:14 -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 TRVXXyl4Mftq for ; Thu, 14 Jul 2011 02:27:13 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DB22E21F8713 for ; Thu, 14 Jul 2011 02:27:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0038528000327; Thu, 14 Jul 2011 11:27:04 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXq-RpRf8V32; Thu, 14 Jul 2011 11:27:03 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D44D428000198; Thu, 14 Jul 2011 11:26:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.22]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 11:26:53 +0200 From: Dirk Kutscher To: Bob Briscoe , "conex@ietf.org" Thread-Topic: [conex] New concepts text in draft-ietf-conex-concepts-uses Thread-Index: AQHMP+4HeYTPeC4NN0WW41701ewYpZTrgLlQ Date: Thu, 14 Jul 2011 09:26:52 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52491CC61C0D@DAPHNIS.office.hd> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> In-Reply-To: <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] New concepts text 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, 14 Jul 2011 09:27:14 -0000 Hi Bob and all, Thanks for the update and apologies for the late feedback -- here's one com= ment: It's good to have 'congestion volume' defined (and the definition is correc= t IMO), but I don't think the 'blame' terminology is very helpful here. I u= nderstand what you want to say, but I fear that it will be misleading. Especially I find it misleading to talk about "blaming network operators" i= n the beginning of section 2. I understand the motivation with the upstream= /downstream congestion exposure for inter-provider accountability, but you = assume that concept to be understood when talking about "how badly the netw= ork operator is to blame", whereas you actually describe it later. I think what we ought to say is that congestion normally occurs in capacity= -shared networks (nobody is to blame for that), and that it will be useful = to expose such congestion for different reasons: to optimize the capacity s= haring between users, to support operators to adjust capacity sharing polic= ies (or to adjust capacity), to evaluate network performance with respect t= o congestion etc. (detailed use cases to be described elsewhere). Congestion volume is a metric for accounting for congestion (with your defi= nition), and this metric could for example be used for 1) quantifying per-u= ser/flow contribution (adding the details of your first example) and for 2)= assessing congestion in inter-provider settings (also adding details). Best regards, Dirk > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: Monday, July 11, 2011 7:14 PM > To: conex@ietf.org > Subject: [conex] New concepts text in draft-ietf-conex-concepts-uses >=20 > All, >=20 > Please give feedback on the proposed new Concepts text below that > precedes the definitions. >=20 > Altho the doc is meant to be about concepts, in -01 the main concepts > were defined but not explained. So, I felt the definitions smacked > you in the face without any warning, and it wasn't ever explained why > you needed them. >=20 > I've also pasted proposed changes to the definitions section below, > because I've changed a couple of definitions: > - I've clarified the definition of congestion, because there were > three conflicting statements: in the introduction, the definitions > section and abstract-mech. > - I've made a big change to congestion-volume, which was previously > defined as congestion-rate multiplied by time. >=20 > I've also added the units each metric is measured in. >=20 > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \ > 2. Concepts >=20 > Despite its central role in network control and management, > congestion is a remarkably hard concept to define. [Bauer09] > provides a good academic background. For the purposes of ConEx, > the > definition below focuses on how congestion would be measured, > rather > than precisely what it is. Our definition of congestion is then > equivalent to the loss probability (or the marking probability if > ECN > is used). >=20 > ConEx is essentially about accountability for congestion (or blame > in > crude language). The blame for congestion lies equally between too > little capacity and too much traffic. On the capacity side, > congestion itself measures how badly the network provider is to > blame. On the traffic side, in a shared network, the blame is > split > among all the users. Congestion-volume measures how much of each > user's traffic is to blame for the congestion. Note that > congestion- > volume is a property of traffic, whereas congestion is a property > of > a link or a path. >=20 >=20 >=20 > Briscoe & Woundy Expires January 8, 2012 [Page > 5] >=20 > Internet-Draft ConEx Concepts & Use Cases July > 2011 >=20 >=20 > Congestion-volume is a relatively newly defined metric that is > central to ConEx. To grasp an intuitive feel for what congestion- > volume measures, some network operators give you an allowance and > only count data volume during the peak period against it. This is > equivalent to counting your congestion-volume by assuming that > congestion is 100% during the peak period and 0% otherwise. >=20 > The congestion-volume metric is more refined but broadly equivalent, > and still as simple to measure as the above time-of-day volume. > Imagine Alice sends 1GB while the loss-probability is a constant > 0.2%. Then her contribution to congestion (or congestion-volume) > is > 1GB x 0.2% =3D 2MB. If she then sends 3GB while congestion is 0.1%, > this adds 3MB to her congestion-volume. Her total contribution to > congestion is then 2MB+3MB =3D 5MB. >=20 > To measure Alice's congestion-volume no-one has to do all these > multiplications and additions. It is simply a matter of counting > the > total volume of Alice's traffic that was discarded (a queue with a > percentage loss involves multiplication inherently). >=20 > Finally, there is yet another way to cut the blame for congestion. > Recall that the level of congestion itself measures the provider's > blame. However, in an internetwork there are multiple providers. > If > a data centre network with zero congestion is connected to an > access > network and sends traffic over a link with 0.4% loss probability, > then clearly all the blame for congestion lies with the access > network. However, at another time, there might be 0.1% congestion > across the data centre and 0.7% across the access, making 0.8% end- > to-end congestion across the path. >=20 > In order to apportion blame accordingly, ConEx is designed so that > a > meter at the border can see how much of the congestion is on one > side > or other, termed upstream and downstream congestion. >=20 > If A and B are connected within a chain of more than two networks, > A > attributes all congestion beyond B to B, and vice versa. As far as > A > is concerned, B chooses who to route to, so B takes responsibility > for its choices. >=20 > 2.1. Definitions >=20 > Congestion: Congestion occurs when any user's traffic suffers > increased delay, loss or ECN marking as a result of one or more > network resources becoming overloaded. For the purposes of > ConEx, > the focus is on concrete signals of congestion (ECN and loss), > therefore delay is set to one side. Congestion is measured as > the > probability of loss or the probability of ECN marking, usually > expressed as dimensionless percentages. >=20 >=20 >=20 > Briscoe & Woundy Expires January 8, 2012 [Page > 6] >=20 > Internet-Draft ConEx Concepts & Use Cases July > 2011 >=20 >=20 > Congestion-volume: For any granularity of traffic (packet, flow, > aggregate, link, etc.), the volume of bytes dropped or marked in > a > given period of time. Conceptually, data volume multiplied by > the > instantaneous congestion each packet of the volume experienced. > Usually expressed in bytes (or MB, GB, of course). >=20 > Congestion-rate: For any granularity of traffic (packet, flow, > aggregate, link, etc.), the instantaneous rate of traffic > discarded or marked due to congestion. Conceptually, the > instantaneous bit-rate of the traffic weighted by the > instantaneous congestion it experiences. Usually expressed in > b/s. >=20 > Upstream Congestion: The accumulated level of congestion > experienced > by a traffic flow thus far, relative to a point along its path. > In other words, at any point the Upstream Congestion is the > accmulated level of congestion the traffic flow has experienced > as > it travels from the sender to that point. At the receiver this > is > equivalent to the end-to-end congestion level that (usually) is > reported back to the sender. >=20 > Downstream Congestion: The level of congestion a flow of traffic > is > expected to experience on the remainder of its path. In other > words, at any point the Downstream Congestion is the level of > congestion the traffic flow is yet to experience as it travels > from that point to the receiver. Aka. Rest-of-Path Congestion. >=20 > Consumer: A general term representing the contractual entity such > as > a user or business or institution that uses the service of a > network provider. There is no implication that the contract has > to be commercial; for instance the consumers of a University or > enterprise network service would be students or employees and > they > might well be required to comply with some form of contract or > acceptable use policy. There is also no implication that the > consumer is necessarily an end-consumer. Where two networks > form > a customer-provider relationship, the term consumer is also > intended to cover the customer network. >=20 > Network provider: (also 'operator'): the term is not confined to > Internet service providers (ISPs) who run commercial public > networks but is also intended to generalise to operators of > enterprise, campus and other networks. >=20 > [ConEx-Abstract-Mech] gives further definitions for aspects of > ConEx > to do with protocol mechanisms. >=20 >=20 >=20 >=20 >=20 >=20 > Briscoe & Woundy Expires January 8, 2012 [Page > 7] >=20 > Internet-Draft ConEx Concepts & Use Cases July > 2011 >=20 >=20 > 2.2. Non-Goals of ConEx and Common Misconceptions >=20 > [continues as pasted into an earlier thread...] > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \ >=20 >=20 >=20 > Bob >=20 > At 18:45 07/07/2011, Bob Briscoe wrote: > >Phil, > > > >>Other comments: > >>'concepts' rather than 'definitions' is great. The current page > >>count in the ToC suggests you only have text under 'definitions'. > >>Suggest you work as much as possible, ie describe the concepts! >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Thu Jul 14 02:56: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 C78C621F86D7 for ; Thu, 14 Jul 2011 02:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 RIu-0ep6UAne for ; Thu, 14 Jul 2011 02:56:11 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id ACAFB21F86D6 for ; Thu, 14 Jul 2011 02:56:10 -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, 14 Jul 2011 10:56:08 +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, 14 Jul 2011 10:56:08 +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 131063736618; Thu, 14 Jul 2011 10:56:06 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.129.85]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6E9u5sK030640; Thu, 14 Jul 2011 10:56:05 +0100 Message-Id: <201107140956.p6E9u5sK030640@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Jul 2011 10:56:03 +0100 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: References: <20110712000701.513.38329.idtracker@ietfa.amsl.com> <201107121207.p6CC7fSG020823@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 Jul 2011 09:56:08.0672 (UTC) FILETIME=[41227600:01CC420C] Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:56:11 -0000 Mikael, At 06:54 13/07/2011, Mikael Abrahamsson wrote: >On Tue, 12 Jul 2011, Bob Briscoe wrote: > >>Are you sure all your comments apply to the -02 revision? > >I opened a lot of documents and tabs yesterday to read up on all >published documents in CONEX, I probably indeed have messed up and >had multiple revisions. > >So, now re-reading > which >I hope is correct. > >I'll take your reply in consideration and start anew on my comments: > >So, congestion volume description starts to make sense, for me as a >router guy this now is "any packet that couldn't be sent immediately >(or within a very low buffer threshold value) or which was over the >rate a policer was configured to. This, however, is NOT ECN marking , Why have you suddenly decided this has to be anything over a v low threshold and therefore doesn't fit with ECN? > so basically to interoperate with non-ECN traffic, there needs to > be a new flag (or one needs to start marking/dropping (if it's ECN > enabled packet or not) very early in the queue depth). Just to make > an example, I would like to have end systems consider a link > congested as soon as a packet was buffered more than 1ms, that > doesn't mean I want to start dropping non-ECN packet at that level, > so what do we do? There's no need to change anything at all in queues to do ConEx. I'm not sure where all this about changing AQM has suddenly come from? >With the current scheme, if I have a WRED profile that starts >marking/dropping at 30ms queue depth, I'd consider this quite >heavily congested before the current scheme would do so. So how >should operators configure their AQM to work best in a conex world? The dependency is the other way round. ConEx just reflects whatever congestion the AQM signals. If the AQM is good without ConEx, it's good with ConEx. If an operator wants shallow queues in their buffers, they should do that, irrespective of ConEx (or not ConEx). >I also imagine it should be different depending on link speed and >amount of users sharing that link (ie a 100GE core link should have >different AQM from a 10 meg user access line). I believe >recommendations in this area are needed. I'll start another thread, as these are interesting areas for discussion, but they're off the ConEx charter. Might not get to it today tho (another deadline this pm). >In section 4 this is discussed, and for LEDBAT to work, there needs >to be some buffering before TCP starts to consider the link >congested, but LEDBAT would notice it before. How is this signalled, >is LEDBAT just simply more sensitive to delay variations and back >off its rate a lot more aggressively? Yup. >Coming back to "instantaneous", I'd still like this defined a bit >more, I guess we're talking second scale resolution here, or perhaps minutes? Congestion-rate is only mentioned because it can be used as a concept, e.g. as the drain-rate of a congestion-policer. Here a token bucket would 'measure' the congestion-rate in the sense that it would drain at that rate. But a congestion policer never reports the congestion-rate to any management system (e.g. as a sequence of varying numbers). Similarly, bit-rate is used as a concept all over networking. However, usually bit-rate is used within mechanisms, not reported as a number in its own right. So the important part of the definition is how it is measured. The conceptually part is optional - it was an attempt to explain it mathematically. It really does mean instantaneouly in the sense of a short period tending to zero. Definitely not minutes. Certainly per-packet congestion rate really is either 1 or 0. Then over a duration you see a varying probability of getting marks/drops, which determines the congestion-volume over that duration. If you take congestion-volume over a very short period and divide it my the duration of the period, that's the (nearly) instantaneous congestion-rate. Instantaneous bit-rate has similar properties: strictly the bit-rate is either line-rate when transmitting a packet or 0 when not. But over a short period, you can measure a bit-rate, and people happily talk about the instantaneous bit-rate, without worrying that it is strictly either line-rate or zero. >Apart from that I think I read -01 revision, because most of the >things I responded to earlier didn't exist in -02. Understood. -02 is significantly different in sections 1 & 2 particularly. Cheers Bob >-- >Mikael Abrahamsson email: swmike@swm.pp.se ________________________________________________________________ Bob Briscoe, BT Innovate & Design From swmike@swm.pp.se Thu Jul 14 03:13:57 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 E05EF21F8AC9 for ; Thu, 14 Jul 2011 03:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 kqEr-iYSIMLQ for ; Thu, 14 Jul 2011 03:13:57 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4EB21F8ABC for ; Thu, 14 Jul 2011 03:13:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 315B92E1; Thu, 14 Jul 2011 12:13:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2E48B2E0; Thu, 14 Jul 2011 12:13:55 +0200 (CEST) Date: Thu, 14 Jul 2011 12:13:55 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201107140956.p6E9u5sK030640@bagheera.jungle.bt.co.uk> Message-ID: References: <20110712000701.513.38329.idtracker@ietfa.amsl.com> <201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk> <201107140956.p6E9u5sK030640@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 10:13:58 -0000 On Thu, 14 Jul 2011, Bob Briscoe wrote: > Why have you suddenly decided this has to be anything over a v low > threshold and therefore doesn't fit with ECN? I believe the following to be true: Congestion is a fact when there is any buffering or drops. Drop and ECN marking should be equivalent. I don't want to drop packets for non-ECN traffic at very low queue depth. I want to give ECN and non-ECN traffic equal treatment when it comes to dropping (which in ECN is setting the "would have dropped bit"). So in short terms, I want to signal congestion before I drop non-ECN packets with WRED. > There's no need to change anything at all in queues to do ConEx. I'm not > sure where all this about changing AQM has suddenly come from? I feel there is a need to signal congestion at low queue depths, but not to drop the traffic. > It really does mean instantaneouly in the sense of a short period > tending to zero. Definitely not minutes. Certainly per-packet congestion > rate really is either 1 or 0. Then over a duration you see a varying > probability of getting marks/drops, which determines the > congestion-volume over that duration. If you take congestion-volume over > a very short period and divide it my the duration of the period, that's > the (nearly) instantaneous congestion-rate. Oki, for me congestion is basically that there are more than a few packets in the queue a significant amount (let's say 50% to give an example) of a second. In an ideal world, I would like to set a "congestion bit" as soon as the buffer depth reaches more than 1ms worth of packets, but I do not want to drop non-ECN traffic at this depth. But if we now drop my definition of congestion and go back to what I interpret your position to be, then for example, if I have WRED configured to start dropping packets (or set ECN drop bit) at 30ms queue depth on my core links, then that by definition would be congestion signalling. Is the +30ms delay also a congestion signal, and how do the end systems know that this +30ms buffer delay is true? Does it look at the packet delay variance and discern that buffering is likely to be in effect? Does LEDBAT back off when there is PDV? Considering wifi or half duplex links usually induce PDV, I guess this isn't easy either? -- Mikael Abrahamsson email: swmike@swm.pp.se From rs@netapp.com Thu Jul 14 07:55:45 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 1FEB821F8665 for ; Thu, 14 Jul 2011 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 85Prvbbbe+Os for ; Thu, 14 Jul 2011 07:55:44 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id B91F721F8663 for ; Thu, 14 Jul 2011 07:55:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,529,1304319600"; d="scan'208";a="253867817" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 14 Jul 2011 07:55:32 -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 p6EEtWZu024782; Thu, 14 Jul 2011 07:55:32 -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); Thu, 14 Jul 2011 15:55:32 +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: Thu, 14 Jul 2011 15:55:02 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F3A84E8@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt Thread-Index: AcxCDsI9jKHDcBXsRWWY1x3PyQks8wAJO6dQ References: <20110712000701.513.38329.idtracker@ietfa.amsl.com><201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk><201107140956.p6E9u5sK030640@bagheera.jungle.bt.co.uk> From: "Scheffenegger, Richard" To: "Mikael Abrahamsson" , "Bob Briscoe" X-OriginalArrivalTime: 14 Jul 2011 14:55:32.0039 (UTC) FILETIME=[1422BD70:01CC4236] Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:55:45 -0000 Hi Mikael, it surely would have been nice, if there would have been mechanisms to signal better-than-binary congestion levels. There are numerous papers describing what benefits a more granular signaling of congestion (ie. no/light/medium/heavy congestion) could have for transports. However, all these protocols would require all the routers and transport protocols to be changed - thus it won't happen in the internet any time soon... Conex has to do with what is available as congestion signals today (ie. ECN and/or loss; PDV sensitive transports like LEDBAT, Chirp, Compound, (Vegas) could also use that as input signals into Conex though). In order to incentivize ECN over regular TCP, you need to start marking instead of dropping *at the same levels*. Otherwise, the status quo (no ECN deployment in the core routers) will persist indefinitely.=20 Anyway this discussion appears to be orthogonal to what Conex is all about. Basically, however a transport sender obtained the congestion signal (be it loss, marks or increasing one-way-delay), Conex is providing this information to the upstream (from the bottleneck point) part of the network with that information. One discussion not entirely off charter may be to provide means in Conex, to signal different levels of congestion though, at a finer granularity than possible as currently envisioned (all bits in a conex-marked packet are accounted 100% as congestion-volume; if a small packet carried the ECN mark (loss), but a large packet carries the conex mark, you are introducting small errors in the congestion volume. However, I believe these are 2nd order problems... Richard Scheffenegger > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Donnerstag, 14. Juli 2011 12:14 > To: Bob Briscoe > Cc: conex@ietf.org > Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt >=20 > On Thu, 14 Jul 2011, Bob Briscoe wrote: >=20 > > Why have you suddenly decided this has to be anything over a v low > > threshold and therefore doesn't fit with ECN? >=20 > I believe the following to be true: >=20 > Congestion is a fact when there is any buffering or drops. > Drop and ECN marking should be equivalent. > I don't want to drop packets for non-ECN traffic at very low queue > depth. > I want to give ECN and non-ECN traffic equal treatment when it comes to > dropping (which in ECN is setting the "would have dropped bit"). >=20 > So in short terms, I want to signal congestion before I drop non-ECN > packets with WRED. >=20 > > There's no need to change anything at all in queues to do ConEx. I'm > not > > sure where all this about changing AQM has suddenly come from? >=20 > I feel there is a need to signal congestion at low queue depths, but > not > to drop the traffic. >=20 > > It really does mean instantaneouly in the sense of a short period > > tending to zero. Definitely not minutes. Certainly per-packet > congestion > > rate really is either 1 or 0. Then over a duration you see a varying > > probability of getting marks/drops, which determines the > > congestion-volume over that duration. If you take congestion-volume > over > > a very short period and divide it my the duration of the period, > that's > > the (nearly) instantaneous congestion-rate. >=20 > Oki, for me congestion is basically that there are more than a few > packets > in the queue a significant amount (let's say 50% to give an example) of > a > second. >=20 > In an ideal world, I would like to set a "congestion bit" as soon as > the > buffer depth reaches more than 1ms worth of packets, but I do not want > to > drop non-ECN traffic at this depth. >=20 > But if we now drop my definition of congestion and go back to what I > interpret your position to be, then for example, if I have WRED > configured > to start dropping packets (or set ECN drop bit) at 30ms queue depth on > my > core links, then that by definition would be congestion signalling. Is > the > +30ms delay also a congestion signal, and how do the end systems know > that > this +30ms buffer delay is true? Does it look at the packet delay > variance > and discern that buffering is likely to be in effect? Does LEDBAT back > off > when there is PDV? Considering wifi or half duplex links usually induce > PDV, I guess this isn't easy either? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Thu Jul 14 18:31:44 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 3668721F8782 for ; Thu, 14 Jul 2011 18:31:44 -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=[AWL=0.000, 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 IjVC91Jk6Qwb for ; Thu, 14 Jul 2011 18:31:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9515321F877D for ; Thu, 14 Jul 2011 18:31:43 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1A75533C21; Thu, 14 Jul 2011 21:31:43 -0400 (EDT) Date: Thu, 14 Jul 2011 21:31:43 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110715013143.GB32499@verdi> References: <20110712000701.513.38329.idtracker@ietfa.amsl.com> <201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk> <201107140956.p6E9u5sK030640@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 01:31:44 -0000 Mikael Abrahamsson wrote: > > I believe the following to be true: > > Congestion is a fact when there is any buffering or drops. I agree that a definition of congestion which takes note of buffering could be useful; I don't believe it's within our charter to pursue that at the present (though it could posssibly be future work). > Drop and ECN marking should be equivalent. That is the definition we must work under, though in principle it would be nice to have _some_ kind of early-warning signal which comes before any packets may be dropped. > I don't want to drop packets for non-ECN traffic at very low queue depth. > I want to give ECN and non-ECN traffic equal treatment when it comes to > dropping (which in ECN is setting the "would have dropped bit"). I'm not clear how you think you can satisfy both of these... > So in short terms, I want to signal congestion before I drop non-ECN > packets with WRED. A commendable desire! But I think such work is out-of-charter. > ... for me congestion is basically that there are more than a few packets > in the queue a significant amount (let's say 50% to give an example) of a > second. I'm sympathetic to that definition. > In an ideal world, I would like to set a "congestion bit" as soon as the > buffer depth reaches more than 1ms worth of packets, but I do not want to > drop non-ECN traffic at this depth. That sounds like ICCRG work. > But if we now drop my definition of congestion and go back to what I > interpret your position to be, then for example, if I have WRED > configured to start dropping packets (or set ECN drop bit) at 30ms > queue depth on my core links, then that by definition would be > congestion signalling. Yes. ConEx cannot enforce any particular AQM rules. > Is the +30ms delay also a congestion signal, Not to ConEx -- though receivers are free to deduce delay (or even use some delay-based signal which may be standardized in the future) and pass that information back to the sender, we do not expect the sender to inject that as a ConEx Congestion-Expected signal. Nor, IMHO, would such a signal by the sender be useful for our purposes. To us, anything like LEDBAT that backs off due to delay-based signals isn't contributing to "congestion" in the ConEx sense. > and how do the end systems know that this +30ms buffer delay is true? That's totally out-of-scope for ConEx. -- John Leslie From swmike@swm.pp.se Fri Jul 15 00:01: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 24DE321F85A1 for ; Fri, 15 Jul 2011 00:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 JfTTReqsTZWF for ; Fri, 15 Jul 2011 00:01:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C021F8596 for ; Fri, 15 Jul 2011 00:01:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 79D492A1; Fri, 15 Jul 2011 09:00:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 778182A0; Fri, 15 Jul 2011 09:00:59 +0200 (CEST) Date: Fri, 15 Jul 2011 09:00:59 +0200 (CEST) From: Mikael Abrahamsson To: John Leslie In-Reply-To: <20110715013143.GB32499@verdi> Message-ID: References: <20110712000701.513.38329.idtracker@ietfa.amsl.com> <201107121207.p6CC7fSG020823@bagheera.jungle.bt.co.uk> <201107140956.p6E9u5sK030640@bagheera.jungle.bt.co.uk> <20110715013143.GB32499@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 07:01:02 -0000 On Thu, 14 Jul 2011, John Leslie wrote: >> and how do the end systems know that this +30ms buffer delay is true? > > That's totally out-of-scope for ConEx. Wouldn't it be good if ConEx could give guidance to protocol designers how the network behaves and what constitutes a congestion signal in networks? Also to give BCP guidance to network operators and vendors how they should configure the network and how it should behave to work the best way. Just see the bufferbloat discussions which I thought was no news at all, but seems to have been news to some people. There is definitely need of guidance how AQM should be done. Or is this purely ICCRG? -- Mikael Abrahamsson email: swmike@swm.pp.se From bob.briscoe@bt.com Fri Jul 15 02:53: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 4910E21F8558 for ; Fri, 15 Jul 2011 02:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 T9TzVbo6kxRB for ; Fri, 15 Jul 2011 02:53:17 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id E288A21F8557 for ; Fri, 15 Jul 2011 02:53: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); Fri, 15 Jul 2011 10:53: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); Fri, 15 Jul 2011 10:53: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 1310723593630; Fri, 15 Jul 2011 10:53:13 +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 p6F9rB85005156; Fri, 15 Jul 2011 10:53:13 +0100 Message-Id: <201107150953.p6F9rB85005156@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Jul 2011 23:45:31 +0100 To: Dirk Kutscher From: Bob Briscoe In-Reply-To: <82AB329A76E2484D934BBCA77E9F52491CC61C0D@DAPHNIS.office.hd > References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <82AB329A76E2484D934BBCA77E9F52491CC61C0D@DAPHNIS.office.hd> 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: 15 Jul 2011 09:53:15.0216 (UTC) FILETIME=[0428ED00:01CC42D5] Cc: "conex@ietf.org" Subject: Re: [conex] New concepts text 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, 15 Jul 2011 09:53:18 -0000 Dirk, John Leslie also thought blame was not a good concept to use. I tried to say balme is shared between too little capacity and too much traffic, then each side of that further splits down (respectively between providers along the path and between the users sending the traffic). And behind the users sending the traffic there are those receiving it as in the discussion with Mikael. And so on. But I can see that it is easy to pick up one of the later sentences out of context of the original statement that overall blame is shared from the start. I was pleased to have thought of a way of describing all the concepts under the same over-arching framework - just unfortunate it was laden with the guilt of blame :( I will have to find another approach to pulling all the concepts together, or a way to avoid being misinterpreted or parts taken out of context. Bob At 10:26 14/07/2011, Dirk Kutscher wrote: >Hi Bob and all, > >Thanks for the update and apologies for the late feedback -- here's >one comment: > >It's good to have 'congestion volume' defined (and the definition is >correct IMO), but I don't think the 'blame' terminology is very >helpful here. I understand what you want to say, but I fear that it >will be misleading. > >Especially I find it misleading to talk about "blaming network >operators" in the beginning of section 2. I understand the >motivation with the upstream/downstream congestion exposure for >inter-provider accountability, but you assume that concept to be >understood when talking about "how badly the network operator is to >blame", whereas you actually describe it later. > >I think what we ought to say is that congestion normally occurs in >capacity-shared networks (nobody is to blame for that), and that it >will be useful to expose such congestion for different reasons: to >optimize the capacity sharing between users, to support operators to >adjust capacity sharing policies (or to adjust capacity), to >evaluate network performance with respect to congestion etc. >(detailed use cases to be described elsewhere). > >Congestion volume is a metric for accounting for congestion (with >your definition), and this metric could for example be used for 1) >quantifying per-user/flow contribution (adding the details of your >first example) and for 2) assessing congestion in inter-provider >settings (also adding details). > > >Best regards, > >Dirk > > > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of Bob Briscoe > > Sent: Monday, July 11, 2011 7:14 PM > > To: conex@ietf.org > > Subject: [conex] New concepts text in draft-ietf-conex-concepts-uses > > > > All, > > > > Please give feedback on the proposed new Concepts text below that > > precedes the definitions. > > > > Altho the doc is meant to be about concepts, in -01 the main concepts > > were defined but not explained. So, I felt the definitions smacked > > you in the face without any warning, and it wasn't ever explained why > > you needed them. > > > > I've also pasted proposed changes to the definitions section below, > > because I've changed a couple of definitions: > > - I've clarified the definition of congestion, because there were > > three conflicting statements: in the introduction, the definitions > > section and abstract-mech. > > - I've made a big change to congestion-volume, which was previously > > defined as congestion-rate multiplied by time. > > > > I've also added the units each metric is measured in. > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > \ > > 2. Concepts > > > > Despite its central role in network control and management, > > congestion is a remarkably hard concept to define. [Bauer09] > > provides a good academic background. For the purposes of ConEx, > > the > > definition below focuses on how congestion would be measured, > > rather > > than precisely what it is. Our definition of congestion is then > > equivalent to the loss probability (or the marking probability if > > ECN > > is used). > > > > ConEx is essentially about accountability for congestion (or blame > > in > > crude language). The blame for congestion lies equally between too > > little capacity and too much traffic. On the capacity side, > > congestion itself measures how badly the network provider is to > > blame. On the traffic side, in a shared network, the blame is > > split > > among all the users. Congestion-volume measures how much of each > > user's traffic is to blame for the congestion. Note that > > congestion- > > volume is a property of traffic, whereas congestion is a property > > of > > a link or a path. > > > > > > > > Briscoe & Woundy Expires January 8, 2012 [Page > > 5] > > > > Internet-Draft ConEx Concepts & Use Cases July > > 2011 > > > > > > Congestion-volume is a relatively newly defined metric that is > > central to ConEx. To grasp an intuitive feel for what congestion- > > volume measures, some network operators give you an allowance and > > only count data volume during the peak period against it. This is > > equivalent to counting your congestion-volume by assuming that > > congestion is 100% during the peak period and 0% otherwise. > > > > The congestion-volume metric is more refined but broadly equivalent, > > and still as simple to measure as the above time-of-day volume. > > Imagine Alice sends 1GB while the loss-probability is a constant > > 0.2%. Then her contribution to congestion (or congestion-volume) > > is > > 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is 0.1%, > > this adds 3MB to her congestion-volume. Her total contribution to > > congestion is then 2MB+3MB = 5MB. > > > > To measure Alice's congestion-volume no-one has to do all these > > multiplications and additions. It is simply a matter of counting > > the > > total volume of Alice's traffic that was discarded (a queue with a > > percentage loss involves multiplication inherently). > > > > Finally, there is yet another way to cut the blame for congestion. > > Recall that the level of congestion itself measures the provider's > > blame. However, in an internetwork there are multiple providers. > > If > > a data centre network with zero congestion is connected to an > > access > > network and sends traffic over a link with 0.4% loss probability, > > then clearly all the blame for congestion lies with the access > > network. However, at another time, there might be 0.1% congestion > > across the data centre and 0.7% across the access, making 0.8% end- > > to-end congestion across the path. > > > > In order to apportion blame accordingly, ConEx is designed so that > > a > > meter at the border can see how much of the congestion is on one > > side > > or other, termed upstream and downstream congestion. > > > > If A and B are connected within a chain of more than two networks, > > A > > attributes all congestion beyond B to B, and vice versa. As far as > > A > > is concerned, B chooses who to route to, so B takes responsibility > > for its choices. > > > > 2.1. Definitions > > > > Congestion: Congestion occurs when any user's traffic suffers > > increased delay, loss or ECN marking as a result of one or more > > network resources becoming overloaded. For the purposes of > > ConEx, > > the focus is on concrete signals of congestion (ECN and loss), > > therefore delay is set to one side. Congestion is measured as > > the > > probability of loss or the probability of ECN marking, usually > > expressed as dimensionless percentages. > > > > > > > > Briscoe & Woundy Expires January 8, 2012 [Page > > 6] > > > > Internet-Draft ConEx Concepts & Use Cases July > > 2011 > > > > > > Congestion-volume: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the volume of bytes dropped or marked in > > a > > given period of time. Conceptually, data volume multiplied by > > the > > instantaneous congestion each packet of the volume experienced. > > Usually expressed in bytes (or MB, GB, of course). > > > > Congestion-rate: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the instantaneous rate of traffic > > discarded or marked due to congestion. Conceptually, the > > instantaneous bit-rate of the traffic weighted by the > > instantaneous congestion it experiences. Usually expressed in > > b/s. > > > > Upstream Congestion: The accumulated level of congestion > > experienced > > by a traffic flow thus far, relative to a point along its path. > > In other words, at any point the Upstream Congestion is the > > accmulated level of congestion the traffic flow has experienced > > as > > it travels from the sender to that point. At the receiver this > > is > > equivalent to the end-to-end congestion level that (usually) is > > reported back to the sender. > > > > Downstream Congestion: The level of congestion a flow of traffic > > is > > expected to experience on the remainder of its path. In other > > words, at any point the Downstream Congestion is the level of > > congestion the traffic flow is yet to experience as it travels > > from that point to the receiver. Aka. Rest-of-Path Congestion. > > > > Consumer: A general term representing the contractual entity such > > as > > a user or business or institution that uses the service of a > > network provider. There is no implication that the contract has > > to be commercial; for instance the consumers of a University or > > enterprise network service would be students or employees and > > they > > might well be required to comply with some form of contract or > > acceptable use policy. There is also no implication that the > > consumer is necessarily an end-consumer. Where two networks > > form > > a customer-provider relationship, the term consumer is also > > intended to cover the customer network. > > > > Network provider: (also 'operator'): the term is not confined to > > Internet service providers (ISPs) who run commercial public > > networks but is also intended to generalise to operators of > > enterprise, campus and other networks. > > > > [ConEx-Abstract-Mech] gives further definitions for aspects of > > ConEx > > to do with protocol mechanisms. > > > > > > > > > > > > > > Briscoe & Woundy Expires January 8, 2012 [Page > > 7] > > > > Internet-Draft ConEx Concepts & Use Cases July > > 2011 > > > > > > 2.2. Non-Goals of ConEx and Common Misconceptions > > > > [continues as pasted into an earlier thread...] > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > \ > > > > > > > > Bob > > > > At 18:45 07/07/2011, Bob Briscoe wrote: > > >Phil, > > > > > >>Other comments: > > >>'concepts' rather than 'definitions' is great. The current page > > >>count in the ToC suggests you only have text under 'definitions'. > > >>Suggest you work as much as possible, ie describe the concepts! > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From richard_woundy@cable.comcast.com Fri Jul 15 14:35: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 8E55821F8B27 for ; Fri, 15 Jul 2011 14:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.742, 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 f7A5Ii9LEwzP for ; Fri, 15 Jul 2011 14:35:25 -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 595F121F8B15 for ; Fri, 15 Jul 2011 14:35:22 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.44891042; Fri, 15 Jul 2011 15:39:25 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Fri, 15 Jul 2011 17:35:14 -0400 From: "Woundy, Richard" To: Bob Briscoe , Dirk Kutscher Thread-Topic: [conex] New concepts text in draft-ietf-conex-concepts-uses Thread-Index: AQHMQtUJm+K8VYk+BkqPug6Tj+K02JTt5I0A Date: Fri, 15 Jul 2011 21:35:13 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135CF8DE@PACDCEXMB05.cable.comcast.com> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <82AB329A76E2484D934BBCA77E9F52491CC61C0D@DAPHNIS.office.hd> <201107150953.p6F9rB85005156@bagheera.jungle.bt.co.uk> In-Reply-To: <201107150953.p6F9rB85005156@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] New concepts text 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, 15 Jul 2011 21:35:26 -0000 > John Leslie also thought blame was not a good concept to use. My personal opinion is that the issue with 'blame' is about terminology imp= lying a (negative) moral judgment, rather than about the concept of account= ability. According to Wikipedia, "Blame is the act of censuring, holding re= sponsible, making negative statements about an individual or group that the= ir action or actions are socially or morally irresponsible". Perhaps we should consider substituting non-judgmental terms like 'accounti= ng', 'attribution', or even 'source'. -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of B= ob Briscoe Sent: Thursday, July 14, 2011 6:46 PM To: Dirk Kutscher Cc: conex@ietf.org Subject: Re: [conex] New concepts text in draft-ietf-conex-concepts-uses Dirk, John Leslie also thought blame was not a good concept to use. I tried to say balme is shared between too little capacity and too=20 much traffic, then each side of that further splits down=20 (respectively between providers along the path and between the users=20 sending the traffic). And behind the users sending the traffic there=20 are those receiving it as in the discussion with Mikael. And so on. But I can see that it is easy to pick up one of the later sentences=20 out of context of the original statement that overall blame is shared=20 from the start. I was pleased to have thought of a way of describing all the concepts=20 under the same over-arching framework - just unfortunate it was laden=20 with the guilt of blame :( I will have to find another approach to pulling all the concepts=20 together, or a way to avoid being misinterpreted or parts taken out of cont= ext. Bob At 10:26 14/07/2011, Dirk Kutscher wrote: >Hi Bob and all, > >Thanks for the update and apologies for the late feedback -- here's=20 >one comment: > >It's good to have 'congestion volume' defined (and the definition is=20 >correct IMO), but I don't think the 'blame' terminology is very=20 >helpful here. I understand what you want to say, but I fear that it=20 >will be misleading. > >Especially I find it misleading to talk about "blaming network=20 >operators" in the beginning of section 2. I understand the=20 >motivation with the upstream/downstream congestion exposure for=20 >inter-provider accountability, but you assume that concept to be=20 >understood when talking about "how badly the network operator is to=20 >blame", whereas you actually describe it later. > >I think what we ought to say is that congestion normally occurs in=20 >capacity-shared networks (nobody is to blame for that), and that it=20 >will be useful to expose such congestion for different reasons: to=20 >optimize the capacity sharing between users, to support operators to=20 >adjust capacity sharing policies (or to adjust capacity), to=20 >evaluate network performance with respect to congestion etc.=20 >(detailed use cases to be described elsewhere). > >Congestion volume is a metric for accounting for congestion (with=20 >your definition), and this metric could for example be used for 1)=20 >quantifying per-user/flow contribution (adding the details of your=20 >first example) and for 2) assessing congestion in inter-provider=20 >settings (also adding details). > > >Best regards, > >Dirk > > > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of Bob Briscoe > > Sent: Monday, July 11, 2011 7:14 PM > > To: conex@ietf.org > > Subject: [conex] New concepts text in draft-ietf-conex-concepts-uses > > > > All, > > > > Please give feedback on the proposed new Concepts text below that > > precedes the definitions. > > > > Altho the doc is meant to be about concepts, in -01 the main concepts > > were defined but not explained. So, I felt the definitions smacked > > you in the face without any warning, and it wasn't ever explained why > > you needed them. > > > > I've also pasted proposed changes to the definitions section below, > > because I've changed a couple of definitions: > > - I've clarified the definition of congestion, because there were > > three conflicting statements: in the introduction, the definitions > > section and abstract-mech. > > - I've made a big change to congestion-volume, which was previously > > defined as congestion-rate multiplied by time. > > > > I've also added the units each metric is measured in. > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > \ > > 2. Concepts > > > > Despite its central role in network control and management, > > congestion is a remarkably hard concept to define. [Bauer09] > > provides a good academic background. For the purposes of ConEx, > > the > > definition below focuses on how congestion would be measured, > > rather > > than precisely what it is. Our definition of congestion is then > > equivalent to the loss probability (or the marking probability if > > ECN > > is used). > > > > ConEx is essentially about accountability for congestion (or blame > > in > > crude language). The blame for congestion lies equally between too > > little capacity and too much traffic. On the capacity side, > > congestion itself measures how badly the network provider is to > > blame. On the traffic side, in a shared network, the blame is > > split > > among all the users. Congestion-volume measures how much of each > > user's traffic is to blame for the congestion. Note that > > congestion- > > volume is a property of traffic, whereas congestion is a property > > of > > a link or a path. > > > > > > > > Briscoe & Woundy Expires January 8, 2012 [Page > > 5] > > > > Internet-Draft ConEx Concepts & Use Cases July > > 2011 > > > > > > Congestion-volume is a relatively newly defined metric that is > > central to ConEx. To grasp an intuitive feel for what congestion- > > volume measures, some network operators give you an allowance and > > only count data volume during the peak period against it. This is > > equivalent to counting your congestion-volume by assuming that > > congestion is 100% during the peak period and 0% otherwise. > > > > The congestion-volume metric is more refined but broadly equivalent= , > > and still as simple to measure as the above time-of-day volume. > > Imagine Alice sends 1GB while the loss-probability is a constant > > 0.2%. Then her contribution to congestion (or congestion-volume) > > is > > 1GB x 0.2% =3D 2MB. If she then sends 3GB while congestion is 0.1%= , > > this adds 3MB to her congestion-volume. Her total contribution to > > congestion is then 2MB+3MB =3D 5MB. > > > > To measure Alice's congestion-volume no-one has to do all these > > multiplications and additions. It is simply a matter of counting > > the > > total volume of Alice's traffic that was discarded (a queue with a > > percentage loss involves multiplication inherently). > > > > Finally, there is yet another way to cut the blame for congestion. > > Recall that the level of congestion itself measures the provider's > > blame. However, in an internetwork there are multiple providers. > > If > > a data centre network with zero congestion is connected to an > > access > > network and sends traffic over a link with 0.4% loss probability, > > then clearly all the blame for congestion lies with the access > > network. However, at another time, there might be 0.1% congestion > > across the data centre and 0.7% across the access, making 0.8% end- > > to-end congestion across the path. > > > > In order to apportion blame accordingly, ConEx is designed so that > > a > > meter at the border can see how much of the congestion is on one > > side > > or other, termed upstream and downstream congestion. > > > > If A and B are connected within a chain of more than two networks, > > A > > attributes all congestion beyond B to B, and vice versa. As far as > > A > > is concerned, B chooses who to route to, so B takes responsibility > > for its choices. > > > > 2.1. Definitions > > > > Congestion: Congestion occurs when any user's traffic suffers > > increased delay, loss or ECN marking as a result of one or more > > network resources becoming overloaded. For the purposes of > > ConEx, > > the focus is on concrete signals of congestion (ECN and loss), > > therefore delay is set to one side. Congestion is measured as > > the > > probability of loss or the probability of ECN marking, usually > > expressed as dimensionless percentages. > > > > > > > > Briscoe & Woundy Expires January 8, 2012 [Page > > 6] > > > > Internet-Draft ConEx Concepts & Use Cases July > > 2011 > > > > > > Congestion-volume: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the volume of bytes dropped or marked in > > a > > given period of time. Conceptually, data volume multiplied by > > the > > instantaneous congestion each packet of the volume experienced. > > Usually expressed in bytes (or MB, GB, of course). > > > > Congestion-rate: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the instantaneous rate of traffic > > discarded or marked due to congestion. Conceptually, the > > instantaneous bit-rate of the traffic weighted by the > > instantaneous congestion it experiences. Usually expressed in > > b/s. > > > > Upstream Congestion: The accumulated level of congestion > > experienced > > by a traffic flow thus far, relative to a point along its path. > > In other words, at any point the Upstream Congestion is the > > accmulated level of congestion the traffic flow has experienced > > as > > it travels from the sender to that point. At the receiver this > > is > > equivalent to the end-to-end congestion level that (usually) is > > reported back to the sender. > > > > Downstream Congestion: The level of congestion a flow of traffic > > is > > expected to experience on the remainder of its path. In other > > words, at any point the Downstream Congestion is the level of > > congestion the traffic flow is yet to experience as it travels > > from that point to the receiver. Aka. Rest-of-Path Congestion. > > > > Consumer: A general term representing the contractual entity such > > as > > a user or business or institution that uses the service of a > > network provider. There is no implication that the contract has > > to be commercial; for instance the consumers of a University or > > enterprise network service would be students or employees and > > they > > might well be required to comply with some form of contract or > > acceptable use policy. There is also no implication that the > > consumer is necessarily an end-consumer. Where two networks > > form > > a customer-provider relationship, the term consumer is also > > intended to cover the customer network. > > > > Network provider: (also 'operator'): the term is not confined to > > Internet service providers (ISPs) who run commercial public > > networks but is also intended to generalise to operators of > > enterprise, campus and other networks. > > > > [ConEx-Abstract-Mech] gives further definitions for aspects of > > ConEx > > to do with protocol mechanisms. > > > > > > > > > > > > > > Briscoe & Woundy Expires January 8, 2012 [Page > > 7] > > > > Internet-Draft ConEx Concepts & Use Cases July > > 2011 > > > > > > 2.2. Non-Goals of ConEx and Common Misconceptions > > > > [continues as pasted into an earlier thread...] > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > \ > > > > > > > > Bob > > > > At 18:45 07/07/2011, Bob Briscoe wrote: > > >Phil, > > > > > >>Other comments: > > >>'concepts' rather than 'definitions' is great. The current page > > >>count in the ToC suggests you only have text under 'definitions'. > > >>Suggest you work as much as possible, ie describe the concepts! > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Sat Jul 16 03:51: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 A2A3D21F84EB for ; Sat, 16 Jul 2011 03:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.401, 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 IgKuc98DeNqd for ; Sat, 16 Jul 2011 03:51:09 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2312721F84EA for ; Sat, 16 Jul 2011 03:51:09 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M689C-1Rg45z34OI-00xUi1; Sat, 16 Jul 2011 12:51:07 +0200 From: "Toby Moncaster" To: "'Woundy, Richard'" , "'Bob Briscoe'" , "'Dirk Kutscher'" References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <82AB329A76E2484D934BBCA77E9F52491CC61C0D@DAPHNIS.office.hd> <201107150953.p6F9rB85005156@bagheera.jungle.bt.co.uk> <1CA25301D2219F40B3AA37201F0EACD1135CF8DE@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1135CF8DE@PACDCEXMB05.cable.comcast.com> Date: Sat, 16 Jul 2011 11:51:01 +0100 Message-ID: <001301cc43a6$4296c130$c7c44390$@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: AQHMQtUJm+K8VYk+BkqPug6Tj+K02JTt5I0AgADhY0A= Content-Language: en-gb X-Provags-ID: V02:K0:fShiZNsJZdZr9jJEYcSFbvGsUGG1Vh7rwEfAHA1izKt UHiN/MY5hZaCxFdTtU3bUWE35oetvJwwQYTPxXtkyUFVFOCJsP +aSO5o3JQQLuD6TXy0MmRigPQvYIVATMnShixC+Bn+H/k/DvEJ bwHFA6rk3EwT6t+Lqe9MrqC7BFbHarNlNk6evKTLOeiO2aybCP ylhvVj8wJ+1AeWjYzSy21/T9uMAkE6OCBnRPkXL5Gw= Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 16 Jul 2011 10:51:10 -0000 I agree that "blame" is far too negative a word to be using. If anything we should be saying that there is no blame-- after all congestion is a by-product of using the network. What we are trying to do is make people accountable for that use, and in turn, make the operators accountable for their network provisioning. Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Woundy, Richard > Sent: 15 July 2011 22:35 > To: Bob Briscoe; Dirk Kutscher > Cc: conex@ietf.org > Subject: Re: [conex] New concepts text in draft-ietf-conex-concepts- > uses > > > John Leslie also thought blame was not a good concept to use. > > My personal opinion is that the issue with 'blame' is about terminology > implying a (negative) moral judgment, rather than about the concept of > accountability. According to Wikipedia, "Blame is the act of censuring, > holding responsible, making negative statements about an individual or > group that their action or actions are socially or morally > irresponsible". > > Perhaps we should consider substituting non-judgmental terms like > 'accounting', 'attribution', or even 'source'. > > -- Rich > > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: Thursday, July 14, 2011 6:46 PM > To: Dirk Kutscher > Cc: conex@ietf.org > Subject: Re: [conex] New concepts text in draft-ietf-conex-concepts- > uses > > Dirk, > > John Leslie also thought blame was not a good concept to use. > > I tried to say balme is shared between too little capacity and too > much traffic, then each side of that further splits down > (respectively between providers along the path and between the users > sending the traffic). And behind the users sending the traffic there > are those receiving it as in the discussion with Mikael. And so on. > > But I can see that it is easy to pick up one of the later sentences > out of context of the original statement that overall blame is shared > from the start. > > I was pleased to have thought of a way of describing all the concepts > under the same over-arching framework - just unfortunate it was laden > with the guilt of blame :( > > I will have to find another approach to pulling all the concepts > together, or a way to avoid being misinterpreted or parts taken out of > context. > > > > Bob > > At 10:26 14/07/2011, Dirk Kutscher wrote: > >Hi Bob and all, > > > >Thanks for the update and apologies for the late feedback -- here's > >one comment: > > > >It's good to have 'congestion volume' defined (and the definition is > >correct IMO), but I don't think the 'blame' terminology is very > >helpful here. I understand what you want to say, but I fear that it > >will be misleading. > > > >Especially I find it misleading to talk about "blaming network > >operators" in the beginning of section 2. I understand the > >motivation with the upstream/downstream congestion exposure for > >inter-provider accountability, but you assume that concept to be > >understood when talking about "how badly the network operator is to > >blame", whereas you actually describe it later. > > > >I think what we ought to say is that congestion normally occurs in > >capacity-shared networks (nobody is to blame for that), and that it > >will be useful to expose such congestion for different reasons: to > >optimize the capacity sharing between users, to support operators to > >adjust capacity sharing policies (or to adjust capacity), to > >evaluate network performance with respect to congestion etc. > >(detailed use cases to be described elsewhere). > > > >Congestion volume is a metric for accounting for congestion (with > >your definition), and this metric could for example be used for 1) > >quantifying per-user/flow contribution (adding the details of your > >first example) and for 2) assessing congestion in inter-provider > >settings (also adding details). > > > > > >Best regards, > > > >Dirk > > > > > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > > Of Bob Briscoe > > > Sent: Monday, July 11, 2011 7:14 PM > > > To: conex@ietf.org > > > Subject: [conex] New concepts text in draft-ietf-conex-concepts- > uses > > > > > > All, > > > > > > Please give feedback on the proposed new Concepts text below that > > > precedes the definitions. > > > > > > Altho the doc is meant to be about concepts, in -01 the main > concepts > > > were defined but not explained. So, I felt the definitions smacked > > > you in the face without any warning, and it wasn't ever explained > why > > > you needed them. > > > > > > I've also pasted proposed changes to the definitions section below, > > > because I've changed a couple of definitions: > > > - I've clarified the definition of congestion, because there were > > > three conflicting statements: in the introduction, the definitions > > > section and abstract-mech. > > > - I've made a big change to congestion-volume, which was previously > > > defined as congestion-rate multiplied by time. > > > > > > I've also added the units each metric is measured in. > > > > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > \ > > > 2. Concepts > > > > > > Despite its central role in network control and management, > > > congestion is a remarkably hard concept to define. [Bauer09] > > > provides a good academic background. For the purposes of > ConEx, > > > the > > > definition below focuses on how congestion would be measured, > > > rather > > > than precisely what it is. Our definition of congestion is > then > > > equivalent to the loss probability (or the marking probability > if > > > ECN > > > is used). > > > > > > ConEx is essentially about accountability for congestion (or > blame > > > in > > > crude language). The blame for congestion lies equally between > too > > > little capacity and too much traffic. On the capacity side, > > > congestion itself measures how badly the network provider is to > > > blame. On the traffic side, in a shared network, the blame is > > > split > > > among all the users. Congestion-volume measures how much of > each > > > user's traffic is to blame for the congestion. Note that > > > congestion- > > > volume is a property of traffic, whereas congestion is a > property > > > of > > > a link or a path. > > > > > > > > > > > > Briscoe & Woundy Expires January 8, 2012 > [Page > > > 5] > > > > > > Internet-Draft ConEx Concepts & Use Cases July > > > 2011 > > > > > > > > > Congestion-volume is a relatively newly defined metric that is > > > central to ConEx. To grasp an intuitive feel for what > congestion- > > > volume measures, some network operators give you an allowance > and > > > only count data volume during the peak period against it. This > is > > > equivalent to counting your congestion-volume by assuming that > > > congestion is 100% during the peak period and 0% otherwise. > > > > > > The congestion-volume metric is more refined but broadly > equivalent, > > > and still as simple to measure as the above time-of-day volume. > > > Imagine Alice sends 1GB while the loss-probability is a > constant > > > 0.2%. Then her contribution to congestion (or congestion- > volume) > > > is > > > 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is > 0.1%, > > > this adds 3MB to her congestion-volume. Her total contribution > to > > > congestion is then 2MB+3MB = 5MB. > > > > > > To measure Alice's congestion-volume no-one has to do all these > > > multiplications and additions. It is simply a matter of > counting > > > the > > > total volume of Alice's traffic that was discarded (a queue > with a > > > percentage loss involves multiplication inherently). > > > > > > Finally, there is yet another way to cut the blame for > congestion. > > > Recall that the level of congestion itself measures the > provider's > > > blame. However, in an internetwork there are multiple > providers. > > > If > > > a data centre network with zero congestion is connected to an > > > access > > > network and sends traffic over a link with 0.4% loss > probability, > > > then clearly all the blame for congestion lies with the access > > > network. However, at another time, there might be 0.1% > congestion > > > across the data centre and 0.7% across the access, making 0.8% > end- > > > to-end congestion across the path. > > > > > > In order to apportion blame accordingly, ConEx is designed so > that > > > a > > > meter at the border can see how much of the congestion is on > one > > > side > > > or other, termed upstream and downstream congestion. > > > > > > If A and B are connected within a chain of more than two > networks, > > > A > > > attributes all congestion beyond B to B, and vice versa. As > far as > > > A > > > is concerned, B chooses who to route to, so B takes > responsibility > > > for its choices. > > > > > > 2.1. Definitions > > > > > > Congestion: Congestion occurs when any user's traffic suffers > > > increased delay, loss or ECN marking as a result of one or > more > > > network resources becoming overloaded. For the purposes of > > > ConEx, > > > the focus is on concrete signals of congestion (ECN and > loss), > > > therefore delay is set to one side. Congestion is measured > as > > > the > > > probability of loss or the probability of ECN marking, > usually > > > expressed as dimensionless percentages. > > > > > > > > > > > > Briscoe & Woundy Expires January 8, 2012 > [Page > > > 6] > > > > > > Internet-Draft ConEx Concepts & Use Cases July > > > 2011 > > > > > > > > > Congestion-volume: For any granularity of traffic (packet, > flow, > > > aggregate, link, etc.), the volume of bytes dropped or > marked in > > > a > > > given period of time. Conceptually, data volume multiplied > by > > > the > > > instantaneous congestion each packet of the volume > experienced. > > > Usually expressed in bytes (or MB, GB, of course). > > > > > > Congestion-rate: For any granularity of traffic (packet, flow, > > > aggregate, link, etc.), the instantaneous rate of traffic > > > discarded or marked due to congestion. Conceptually, the > > > instantaneous bit-rate of the traffic weighted by the > > > instantaneous congestion it experiences. Usually expressed > in > > > b/s. > > > > > > Upstream Congestion: The accumulated level of congestion > > > experienced > > > by a traffic flow thus far, relative to a point along its > path. > > > In other words, at any point the Upstream Congestion is the > > > accmulated level of congestion the traffic flow has > experienced > > > as > > > it travels from the sender to that point. At the receiver > this > > > is > > > equivalent to the end-to-end congestion level that (usually) > is > > > reported back to the sender. > > > > > > Downstream Congestion: The level of congestion a flow of > traffic > > > is > > > expected to experience on the remainder of its path. In > other > > > words, at any point the Downstream Congestion is the level > of > > > congestion the traffic flow is yet to experience as it > travels > > > from that point to the receiver. Aka. Rest-of-Path > Congestion. > > > > > > Consumer: A general term representing the contractual entity > such > > > as > > > a user or business or institution that uses the service of a > > > network provider. There is no implication that the contract > has > > > to be commercial; for instance the consumers of a University > or > > > enterprise network service would be students or employees > and > > > they > > > might well be required to comply with some form of contract > or > > > acceptable use policy. There is also no implication that > the > > > consumer is necessarily an end-consumer. Where two networks > > > form > > > a customer-provider relationship, the term consumer is also > > > intended to cover the customer network. > > > > > > Network provider: (also 'operator'): the term is not confined > to > > > Internet service providers (ISPs) who run commercial public > > > networks but is also intended to generalise to operators of > > > enterprise, campus and other networks. > > > > > > [ConEx-Abstract-Mech] gives further definitions for aspects of > > > ConEx > > > to do with protocol mechanisms. > > > > > > > > > > > > > > > > > > > > > Briscoe & Woundy Expires January 8, 2012 > [Page > > > 7] > > > > > > Internet-Draft ConEx Concepts & Use Cases July > > > 2011 > > > > > > > > > 2.2. Non-Goals of ConEx and Common Misconceptions > > > > > > [continues as pasted into an earlier thread...] > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > \ > > > > > > > > > > > > Bob > > > > > > At 18:45 07/07/2011, Bob Briscoe wrote: > > > >Phil, > > > > > > > >>Other comments: > > > >>'concepts' rather than 'definitions' is great. The current page > > > >>count in the ToC suggests you only have text under 'definitions'. > > > >>Suggest you work as much as possible, ie describe the concepts! > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT Innovate & Design > > > > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > 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 marcelo@it.uc3m.es Sun Jul 17 06:48: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 3300B21F85EC for ; Sun, 17 Jul 2011 06:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 pABkZuBoE1ep for ; Sun, 17 Jul 2011 06:48:09 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id CB08021F8698 for ; Sun, 17 Jul 2011 06:48:05 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 09466C28857 for ; Sun, 17 Jul 2011 15:48:00 +0200 (CEST) Message-ID: <4E22E80E.1070805@it.uc3m.es> Date: Sun, 17 Jul 2011 15:47:58 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 'ConEx IETF list' 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.8.0.1017-18266.007 Subject: [conex] draft-ietf-conex-abstract-mech-02 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, 17 Jul 2011 13:48:10 -0000 Hi, Some comments about this draft, speaking as an individual contributor. I think this draft look very good and most of it is very clear. Substantial: In the intro it reads: For the avoidance of doubt, there is no expectation that internetwork layer devices will do fine-grained congestion control using ConEx information. But the audit function is likely to do per flow processing, so it seems a bit confusing. In section 2 it reads: Given that loss-based and ECN-based ConEx might sometimes be best audited at different locations, having distinct encodings would widen the design space for the auditing function. Using the same encoding for both signals is likely to make one of the auditing techniques infeasible, and the others less accurate. This seems to imply that there will a different encoding when congestion is exposed based on ECN info and when it is obtained from losses. Is that what this means? This would increase the amount of code points needed, correct? This is not considered in the encoding section, in particular in 3.3 where the signals are described, there is no differentiation when the congestion is ecn or losses, shoudln't this be included there as well? In section 3.1, i believe that the strawmand encoding should be the IPv6 encoding that conex is defining rather than an encoding that we will not use. Similarly with section 3.2. My suggestion is to move section 3.1 and section 3.2 to an appendix where alternative encodings are discussed and keep in this section a short description of the v6 encoding we are working on. Later on section 4.3 it reads: " Ideally, ConEx should be added to a transport like TCP without mandatory modifications to the receiver. But an optional modification to the receiver could be recommended for precision." I don't understand what this means, maybe it would be useful to expand a bit? Later on in section 4.4.1. I still have a hard time to understand the credit. I understand the problem it is trying to solve, but i can't really understand how the credit soves the problem out of the proposed text. In the same section, it reads: " The one-way nature of packet forwarding probably makes per-flow state unavoidable for the audit function. This was a necessary sacrifice to avoid per-flow state elsewhere in the wider ConEx architecture. Nonetheless, care was taken to ensure that packets could bring soft- state to the audit function, so that it would continue to work if a flow shifted to a different audit device, perhaps after a reroute or an audit device failure. Therefore, although the audit function is likely to need flow state memory, at least it complies with the 'fate-sharing' design principle of the Internet [IntDesPrinciples], and at least per-flow audit is only required at the outer edges of the internetwork, where it is less of a scalability concern. Note also that ConEx does not intend to embed rules in the network on how individual flows _behave_. The audit function only does per-flow processing to check the integrity of ConEx _information_." I don't think these 2 paragraphs belong to the credit section (i mean there si nothing specific to the credity in them afaict, but they are generic to the audit function). I think they belong to section 4.4.2 Editorial In the abstract: s/The mechanism to be developed by the ConEx WG/ The ConEx mechanism Overall the document, capitalize the first letters of acronym expansion. For example, in the Introduction: s/explicit congestion notification (ECN)/Explicit Congestion Notification (ECN) s/ip header/IP header later on, in the same situation are: RNC, BRAS, DSL As a matter of taste, i personally preffer using the IP layer term instead of the intenetwork layer. In section 2: I suggest to split requirement a) into multiple requirements. I mean, visibility and inmutability are different requirements. From bob.briscoe@bt.com Sun Jul 17 12:02: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 2E24321F86BF for ; Sun, 17 Jul 2011 12:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.423 X-Spam-Level: X-Spam-Status: No, score=-4.423 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOsDHTCU24Iq for ; Sun, 17 Jul 2011 12:02:31 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5226221F86BC for ; Sun, 17 Jul 2011 12:02:31 -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); Sun, 17 Jul 2011 20:02:29 +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, 17 Jul 2011 20:02:29 +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 1310929341537; Sun, 17 Jul 2011 20:02:21 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.16.91]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6HJ2QBl022028; Sun, 17 Jul 2011 20:02:26 +0100 Message-Id: <201107171902.p6HJ2QBl022028@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 17 Jul 2011 20:02:25 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4E22E80E.1070805@it.uc3m.es> References: <4E22E80E.1070805@it.uc3m.es> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_195228954==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 17 Jul 2011 19:02:29.0550 (UTC) FILETIME=[134CBCE0:01CC44B4] Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-abstract-mech-02 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, 17 Jul 2011 19:02:33 -0000 --=====================_195228954==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Marcelo, Thanks for these. In general we'll try to fix the points you raise, but one or two responses inline... At 14:47 17/07/2011, marcelo bagnulo braun wrote: >Hi, > >Some comments about this draft, speaking as an individual contributor. > >I think this draft look very good and most of it is very clear. > > > >Substantial: > >In the intro it reads: > > For the avoidance of doubt, there is no expectation that internetwork > layer devices will do fine-grained congestion control using ConEx > information. > >But the audit function is likely to do per flow processing, so it >seems a bit confusing. Is this really confusing? Even though audit might be per-flow, we said this under Audit: " Note also that ConEx does not intend to embed rules in the network on how individual flows _behave_. The audit function only does per-flow processing to check the integrity of ConEx _information_. " I don't see how we can make it any clearer that the two points are not contradictory. We shouldn't say anything in the Intro, because the reader doesn't yet know that audit is per-flow anyway. And when we get to saying audit probably has to be per-flow, we immediately have the above very clear statement that distinguishes audit from congestion control (or anything to do with controlling rate). We are trying to separate out different sorts of per-flow processing, and we are trying to dig under the blanket-ban "per-flow is evil" to the (four) different underlying reasons why per-flow stuff can be harmful, to show we don't contravene the three most critical of them. See , which I suggested to Matt at the time ought to be incorporated into the next rev of abstract-mech. >In section 2 it reads: > > Given that loss-based and ECN-based ConEx might sometimes be best > audited at different locations, having distinct encodings would widen > the design space for the auditing function. Using the same encoding > for both signals is likely to make one of the auditing techniques > infeasible, and the others less accurate. > > >This seems to imply that there will a different encoding when >congestion is exposed based on ECN info and when it is obtained from >losses. Is that what this means? This would increase the amount of >code points needed, correct? This is not considered in the encoding >section, in particular in 3.3 where the signals are described, there >is no differentiation when the congestion is ecn or losses, >shoudln't this be included there as well? I think you've missed it. In both 3.3.1 & 3.3.2 there is both: - Re-Echo-Loss - Re-Echo-ECN >In section 3.1, i believe that the strawmand encoding should be the >IPv6 encoding that conex is defining rather than an encoding that we >will not use. It wouldn't be a strawman if we were using it. A strawman is deliberately simple and naive so that it is easy to understand, but it doesn't stand up to deeper analysis. And in the strawman text it says it's not going to be used because it's IPv4 only and we've been chartered to address v6. >Similarly with section 3.2. My suggestion is to move section 3.1 and >section 3.2 to an appendix where alternative encodings are discussed >and keep in this section a short description of the v6 encoding we >are working on. When Matt first wrote this doc he designed it to state an abstract ideal, even if we have to compromise in the actual encoding (this is all explained at the start of S.3). I liked that approach. It would surely be wrong to reflect back what we have eventually decided to do into the statement of ideal requirements. Having said that, I agree 3.2 doesn't all fit: a) we don't have to say what re-ECN did (altho sometimes it's useful to say how ConEx is different, for people who originally read re-ECN and assume ConEx is the same) b) we do want to describe the implications on transport protocols (esp TCP), but this should be in a section about implications on transport protocols, not in the IP encoding section. Probably best at the end of Section 3. >Later on section 4.3 it reads: >" Ideally, ConEx should be added to a transport like TCP without > mandatory modifications to the receiver. But an optional > modification to the receiver could be recommended for precision." >I don't understand what this means, maybe it would be useful to expand a bit? OK. It's obviously not clear that this refers back to the problem described in the previous para. (the problem is TCP only responds once per RTT to congestion, so the feedback didn't need to be designed to indicate more than this, even if there were more losses/ECN marks per RTT. However, re-ECN needs to reflect all congestion events, not just one per RTT. TCP feedback's accurate enough for losses, especially with SACK, but ECN-feedback needs changing. This was called for in the charter and is the purpose of draft-kuehlewind-conex-accurate-ecn). >Later on in section 4.4.1. I still have a hard time to understand >the credit. I understand the problem it is trying to solve, but i >can't really understand how the credit soves the problem out of the >proposed text. OK. It would probably fix this if we give an example of how credit would work (similar to the presentation in Beijing that Andrea Soppera did on my behalf). >In the same section, it reads: >" The one-way nature of packet forwarding probably makes per-flow state > unavoidable for the audit function. This was a necessary sacrifice > to avoid per-flow state elsewhere in the wider ConEx architecture. > Nonetheless, care was taken to ensure that packets could bring soft- > state to the audit function, so that it would continue to work if a > flow shifted to a different audit device, perhaps after a reroute or > an audit device failure. Therefore, although the audit function is > likely to need flow state memory, at least it complies with the > 'fate-sharing' design principle of the Internet [IntDesPrinciples], > and at least per-flow audit is only required at the outer edges of > the internetwork, where it is less of a scalability concern. > > Note also that ConEx does not intend to embed rules in the network on > how individual flows _behave_. The audit function only does per-flow > processing to check the integrity of ConEx _information_." > > >I don't think these 2 paragraphs belong to the credit section (i >mean there si nothing specific to the credity in them afaict, but >they are generic to the audit function). I think they belong to section 4.4.2 You're right. We ought to put a new sub-section heading "Audit and Per-flow State" before these paras. Thanks for this - always v useful to have a fresh eye look over a draft. Cheers Bob >Editorial > >In the abstract: > >s/The mechanism to be developed by the ConEx WG/ The ConEx mechanism > >Overall the document, capitalize the first letters of acronym expansion. >For example, in the Introduction: > >s/explicit congestion notification (ECN)/Explicit Congestion >Notification (ECN) > >s/ip header/IP header > >later on, in the same situation are: RNC, BRAS, DSL > >As a matter of taste, i personally preffer using the IP layer term >instead of the intenetwork layer. > >In section 2: > >I suggest to split requirement a) into multiple requirements. I >mean, visibility and inmutability are different requirements. > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_195228954==.ALT Content-Type: text/html; charset="us-ascii" Marcelo,

Thanks for these. In general we'll try to fix the points you raise, but one or two responses inline...

At 14:47 17/07/2011, marcelo bagnulo braun wrote:

Hi,

Some comments about this draft, speaking as an individual contributor.

I think this draft look very good and most of it is very clear.



Substantial:

In the intro it reads:

 For the avoidance of doubt, there is no expectation that internetwork
   layer devices will do fine-grained congestion control using ConEx
   information.

But the audit function is likely to do per flow processing, so it seems a bit confusing.

Is this really confusing? Even though audit might be per-flow, we said this under Audit:
"
  Note also that ConEx does not intend to embed rules in
the network on
   how individual flows _behave_.  The audit function only
does per-flow
   processing to check the integrity of ConEx _information_.
"

I don't see how we can make it any clearer that the two points are not contradictory. We shouldn't say anything in the Intro, because the reader doesn't yet know that audit is per-flow anyway. And when we get to saying audit probably has to be per-flow, we immediately have the above very clear statement that distinguishes audit from congestion control (or anything to do with controlling rate).

We are trying to separate out different sorts of per-flow processing, and we are trying to dig under the blanket-ban "per-flow is evil" to the (four) different underlying reasons why per-flow stuff can be harmful, to show we don't contravene the three most critical of them.

See < http://www.ietf.org/mail-archive/web/conex/current/msg00661.html>, which I suggested to Matt at the time ought to be incorporated into the next rev of abstract-mech.


In section 2 it reads:

  Given that loss-based and ECN-based ConEx might sometimes be best
   audited at different locations, having distinct encodings would widen
   the design space for the auditing function.  Using the same encoding
   for both signals is likely to make one of the auditing techniques
   infeasible, and the others less accurate.


This seems to imply that there will a different encoding when congestion is exposed based on ECN info and when it is obtained from losses. Is that what this means? This would increase the amount of code points needed, correct? This is not considered in the encoding section, in particular in 3.3 where the signals are described, there is no differentiation when the congestion is ecn or losses, shoudln't this be included there as well?

I think you've missed it. In both 3.3.1 & 3.3.2 there is both:
- 
Re-Echo-Loss
- 
Re-Echo-ECN
In section 3.1, i believe that the strawmand encoding should be the IPv6 encoding that conex is defining rather than an encoding that we will not use.

It wouldn't be a strawman if we were using it. A strawman is deliberately simple and naive so that it is easy to understand, but it doesn't stand up to deeper analysis.

And in the strawman text it says it's not going to be used because it's IPv4 only and we've been chartered to address v6.

Similarly with section 3.2. My suggestion is to move section 3.1 and section 3.2 to an appendix where alternative encodings are discussed and keep in this section a short description of the v6 encoding we are working on.

When Matt first wrote this doc he designed it to state an abstract ideal, even if we have to compromise in the actual encoding (this is all explained at the start of S.3). I liked that approach. It would surely be wrong to reflect back what we have eventually decided to do into the statement of ideal requirements.

Having said that, I agree 3.2 doesn't all fit:
a) we don't have to say what re-ECN did (altho sometimes it's useful to say how ConEx is different, for people who originally read re-ECN and assume ConEx is the same)
b) we do want to describe the implications on transport protocols (esp TCP), but this should be in a section about implications on transport protocols, not in the IP encoding section. Probably best at the end of Section 3.


Later on section 4.3 it reads:
" Ideally, ConEx should be added to a transport like TCP without
   mandatory modifications to the receiver.  But an optional
   modification to the receiver could be recommended for precision."
I don't understand what this means, maybe it would be useful to expand a bit?

OK. It's obviously not clear that this refers back to the problem described in the previous para. (the problem is TCP only responds once per RTT to congestion, so the feedback didn't need to be designed to indicate more than this, even if there were more losses/ECN marks per RTT. However, re-ECN needs to reflect all congestion events, not just one per RTT. TCP feedback's accurate enough for losses, especially with SACK, but ECN-feedback needs changing. This was called for in the charter and is the purpose of 
draft-kuehlewind-conex-accurate-ecn
).


Later on in section 4.4.1. I still have a hard time to understand the credit. I understand the problem it is trying to solve, but i can't really understand how the credit soves the problem out of the proposed text.

OK. It would probably fix this if we give an example of how credit would work (similar to the presentation in Beijing that Andrea Soppera did on my behalf).


In the same section, it reads:
"   The one-way nature of packet forwarding probably makes per-flow state
   unavoidable for the audit function.  This was a necessary sacrifice
   to avoid per-flow state elsewhere in the wider ConEx architecture.
   Nonetheless, care was taken to ensure that packets could bring soft-
   state to the audit function, so that it would continue to work if a
   flow shifted to a different audit device, perhaps after a reroute or
   an audit device failure.  Therefore, although the audit function is
   likely to need flow state memory, at least it complies with the
   'fate-sharing' design principle of the Internet [IntDesPrinciples],
   and at least per-flow audit is only required at the outer edges of
   the internetwork, where it is less of a scalability concern.

   Note also that ConEx does not intend to embed rules in the network on
   how individual flows _behave_.  The audit function only does per-flow
   processing to check the integrity of ConEx _information_."


I don't think these 2 paragraphs belong to the credit section (i mean there si nothing specific to the credity in them afaict, but they are generic to the audit function). I think they belong to section 4.4.2

You're right. We ought to put a new sub-section heading "Audit and Per-flow State" before these paras.

Thanks for this - always v useful to have a fresh eye look over a draft.

Cheers



Bob



Editorial

In the abstract:

s/The mechanism to be developed by the ConEx WG/ The ConEx mechanism

Overall the document, capitalize the first letters of acronym expansion.
For example, in the Introduction:

s/explicit congestion notification (ECN)/Explicit Congestion Notification (ECN)

s/ip header/IP header

later on, in the same situation are: RNC, BRAS, DSL

As a matter of taste, i personally preffer using the IP layer term instead of the intenetwork layer.

In section 2:

I suggest to split requirement a) into multiple requirements. I mean, visibility and inmutability are different requirements.



_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_195228954==.ALT-- From toby@moncaster.com Sun Jul 17 14:09: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 19D3221F8754 for ; Sun, 17 Jul 2011 14:09:22 -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 5z-Npowj99Qq for ; Sun, 17 Jul 2011 14:09:21 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id C144121F8752 for ; Sun, 17 Jul 2011 14:09:19 -0700 (PDT) Received: from TobysHP (host86-132-207-13.range86-132.btcentralplus.com [86.132.207.13]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LgBIO-1REdjc2RDo-00nfq2; Sun, 17 Jul 2011 23:09:17 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'marcelo bagnulo braun'" References: <4E22E80E.1070805@it.uc3m.es> <201107171902.p6HJ2QBl022028@bagheera.jungle.bt.co.uk> In-Reply-To: <201107171902.p6HJ2QBl022028@bagheera.jungle.bt.co.uk> Date: Sun, 17 Jul 2011 22:09:14 +0100 Message-ID: <004101cc44c5$c89bedd0$59d3c970$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxEtDKPqGJU7z0zRVyv0MqBxb14ygAD8mtw Content-Language: en-gb X-Provags-ID: V02:K0:GsyQkr1ZmegZm6DFbu+m98BONsMhq+GobO4mue+MywV dv7dbGynxbvKW0P0IU+f5nzT737Ro6nIvLBhi8AuqxUr4Y8xol U+769XiAIegNjisvtdK4b/KPHNBKi0mdol2v0TXszA5sdRz5bR nhkY/VFVJj1MVjLHagTv3HhKm24RLVVVAgywSoChdYkW94guUy PKDUB0Jp4/IFa3DgfuaOx020CDc/rnd2eOzdWj4Q8o= Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-abstract-mech-02 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, 17 Jul 2011 21:10:00 -0000 One comment snipped inline marked {TM}=20 As I haven't read the whole draft I can't really comment on more than = this one issue From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf = Of Bob Briscoe Sent: 17 July 2011 20:02 To: marcelo bagnulo braun Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-abstract-mech-02 Substantial: In the intro it reads: =A0For the avoidance of doubt, there is no expectation that internetwork =A0=A0 layer devices will do fine-grained congestion control using ConEx =A0=A0 information. But the audit function is likely to do per flow processing, so it seems = a bit confusing. Is this really confusing?=20 {TM} Unfortunately this does seem to have been confusing to a lot of = people. And that has made them write off ConEx as they assume we are requiring = every device in the network to be upgraded... Even though audit might be per-flow, we said this under Audit: " =A0 Note also that ConEx does not intend to embed rules in the network on =A0=A0 how individual flows _behave_.=A0 The audit function only does per-flow =A0=A0 processing to check the integrity of ConEx _information_. " {TM} I think the issue is that people have such pre-conceived notions of ConEx that they are already assuming it requires per-flow or per-packet processing because that is what things like flow-aware routing = required... =20 I think you could make it clearer that audit only ever really needs be = done at the edges where intelligent "slow path" things exist. I think there = is a wrong belief that ConEx auditing has to be done every time a ConEx mark = is set... I don't see how we can make it any clearer that the two points are not contradictory. We shouldn't say anything in the Intro, because the = reader doesn't yet know that audit is per-flow anyway. And when we get to = saying audit probably has to be per-flow, we immediately have the above very = clear statement that distinguishes audit from congestion control (or anything = to do with controlling rate). {TM} Unfortunately ConEx needs these first two documents to tread a fine line between being cold standards documents and spoon feeding the people that are determined to find problems even where they don't exist... In = other words, if there is still room for misunderstanding you need to tweak the text somehow. If I get a chance I will read the draft and try and give = some actually constructive comments on how to do this, but probably won't = have time before next weekend Toby From marcelo@it.uc3m.es Mon Jul 18 00:15:07 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 C961E21F8AED for ; Mon, 18 Jul 2011 00:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.766 X-Spam-Level: X-Spam-Status: No, score=-106.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 zmP2M0nRHWeX for ; Mon, 18 Jul 2011 00:15:06 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id DF63E21F8AEA for ; Mon, 18 Jul 2011 00:15:02 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 583C7759C5A; Mon, 18 Jul 2011 09:14:57 +0200 (CEST) Message-ID: <4E23DD70.301@it.uc3m.es> Date: Mon, 18 Jul 2011 09:14:56 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Briscoe References: <4E22E80E.1070805@it.uc3m.es> <201107171902.p6HJ2QBl022028@bagheera.jungle.bt.co.uk> In-Reply-To: <201107171902.p6HJ2QBl022028@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.8.0.1017-18268.003 Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-abstract-mech-02 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, 18 Jul 2011 07:15:07 -0000 below i only keep the issues that i don't completelly agree with your replies... El 17/07/11 21:02, Bob Briscoe escribió: >> In section 3.1, i believe that the strawmand encoding should be the >> IPv6 encoding that conex is defining rather than an encoding that we >> will not use. > > It wouldn't be a strawman if we were using it. A strawman is > deliberately simple and naive so that it is easy to understand, but it > doesn't stand up to deeper analysis. > > And in the strawman text it says it's not going to be used because > it's IPv4 only and we've been chartered to address v6. > i understand that What i am suggesting is to include a v6 example, not with all the details of the encoding but simply saying that we encode the information in an ipv6 dest option and that the details are defined later (maybe a reference to suresh draft) I think this would make the document set more coherent. >> Similarly with section 3.2. My suggestion is to move section 3.1 and >> section 3.2 to an appendix where alternative encodings are discussed >> and keep in this section a short description of the v6 encoding we >> are working on. > > When Matt first wrote this doc he designed it to state an abstract > ideal, even if we have to compromise in the actual encoding (this is > all explained at the start of S.3). I liked that approach. i agree with this as well > It would surely be wrong to reflect back what we have eventually > decided to do into the statement of ideal requirements. > i am not sure i understnad what you mean by this > Having said that, I agree 3.2 doesn't all fit: > a) we don't have to say what re-ECN did (altho sometimes it's useful > to say how ConEx is different, for people who originally read re-ECN > and assume ConEx is the same) i am fine with pointing the difference, but as i said, i think this would fit best in an appendix > b) we do want to describe the implications on transport protocols (esp > TCP), but this should be in a section about implications on transport > protocols, not in the IP encoding section. Probably best at the end of > Section 3. > ok > >> Later on section 4.3 it reads: >> " Ideally, ConEx should be added to a transport like TCP without >> mandatory modifications to the receiver. But an optional >> modification to the receiver could be recommended for precision." >> I don't understand what this means, maybe it would be useful to >> expand a bit? > > OK. It's obviously not clear that this refers back to the problem > described in the previous para. (the problem is TCP only responds once > per RTT to congestion, so the feedback didn't need to be designed to > indicate more than this, even if there were more losses/ECN marks per > RTT. However, re-ECN needs to reflect all congestion events, not just > one per RTT. TCP feedback's accurate enough for losses, especially > with SACK, but ECN-feedback needs changing. This was called for in the > charter and is the purpose of > draft-kuehlewind-conex-accurate-ecn > ). > ok, i understand it now. maybe my problem was with the previous paragraph where it states: "The sender may require more precise feedback from the receiver otherwise it is at risk of appearin to be understating its ConEx Signals " It is not clear to me what it means by appearing to be understanding its conex signals. From bob.briscoe@bt.com Mon Jul 18 04:10:15 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 89F9021F8B8C for ; Mon, 18 Jul 2011 04:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 X6Bhb69xi+5d for ; Mon, 18 Jul 2011 04:10:14 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8154D21F8B85 for ; Mon, 18 Jul 2011 04:10:14 -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); Mon, 18 Jul 2011 12:09: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); Mon, 18 Jul 2011 12:09: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 1310987391992; Mon, 18 Jul 2011 12:09:51 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.16.60]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6IB9oPt025820; Mon, 18 Jul 2011 12:09:51 +0100 Message-Id: <201107181109.p6IB9oPt025820@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jul 2011 10:25:34 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4E23DD70.301@it.uc3m.es> References: <4E22E80E.1070805@it.uc3m.es> <201107171902.p6HJ2QBl022028@bagheera.jungle.bt.co.uk> <4E23DD70.301@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: 18 Jul 2011 11:09:53.0621 (UTC) FILETIME=[38431850:01CC453B] Cc: 'ConEx IETF list' Subject: Re: [conex] draft-ietf-conex-abstract-mech-02 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, 18 Jul 2011 11:10:15 -0000 Marcelo, I think we've now converged (assuming Matt also agrees). Responses inline... At 08:14 18/07/2011, marcelo bagnulo braun wrote: >below > >i only keep the issues that i don't completelly agree with your replies... > >El 17/07/11 21:02, Bob Briscoe escribi=F3: >>>In section 3.1, i believe that the strawmand=20 >>>encoding should be the IPv6 encoding that=20 >>>conex is defining rather than an encoding that we will not use. >> >>It wouldn't be a strawman if we were using it.=20 >>A strawman is deliberately simple and naive so=20 >>that it is easy to understand, but it doesn't stand up to deeper analysis. >> >>And in the strawman text it says it's not going=20 >>to be used because it's IPv4 only and we've been chartered to address v6. >i understand that >What i am suggesting is to include a v6 example,=20 >not with all the details of the encoding but=20 >simply saying that we encode the information in=20 >an ipv6 dest option and that the details are=20 >defined later (maybe a reference to suresh draft) > >I think this would make the document set more coherent. Oh certainly (talking for myself, not having=20 checked with my co-author here). I would like to=20 make sure that we refer to every piece of ConEx=20 documentation from somewhere in this doc. Yes, we=20 need to update the doc to talk about more recent work. >>>Similarly with section 3.2. My suggestion is=20 >>>to move section 3.1 and section 3.2 to an=20 >>>appendix where alternative encodings are=20 >>>discussed and keep in this section a short=20 >>>description of the v6 encoding we are working on. >> >>When Matt first wrote this doc he designed it=20 >>to state an abstract ideal, even if we have to=20 >>compromise in the actual encoding (this is all=20 >>explained at the start of S.3). I liked that approach. >i agree with this as well > >>It would surely be wrong to reflect back what=20 >>we have eventually decided to do into the statement of ideal requirements. >i am not sure i understnad what you mean by this We could point to what we've decided to do, but=20 only in the context of comparing it with the=20 ideal, but we have to be clear it is not the same=20 as the ideal. This doc is about the ideal. I=20 would say the v6 encoding is where we should talk=20 about the particular set of compromises made relative to the ideal. >>Having said that, I agree 3.2 doesn't all fit: >>a) we don't have to say what re-ECN did (altho=20 >>sometimes it's useful to say how ConEx is=20 >>different, for people who originally read re-ECN and assume ConEx is the= same) > >i am fine with pointing the difference, but as i=20 >said, i think this would fit best in an appendix Yes, I meant to agree with that. >>b) we do want to describe the implications on=20 >>transport protocols (esp TCP), but this should=20 >>be in a section about implications on transport=20 >>protocols, not in the IP encoding section.=20 >>Probably best at the end of Section 3. > >ok > >> >>>Later on section 4.3 it reads: >>>" Ideally, ConEx should be added to a transport like TCP without >>> mandatory modifications to the receiver. But an optional >>> modification to the receiver could be recommended for precision." >>>I don't understand what this means, maybe it=20 >>>would be useful to expand a bit? >> >>OK. It's obviously not clear that this refers=20 >>back to the problem described in the previous=20 >>para. (the problem is TCP only responds once=20 >>per RTT to congestion, so the feedback didn't=20 >>need to be designed to indicate more than this,=20 >>even if there were more losses/ECN marks per=20 >>RTT. However, re-ECN needs to reflect all=20 >>congestion events, not just one per RTT. TCP=20 >>feedback's accurate enough for losses,=20 >>especially with SACK, but ECN-feedback needs=20 >>changing. This was called for in the charter and is the purpose of >>draft-kuehlewind-conex-accurate-ecn >>). >ok, i understand it now. > >maybe my problem was with the previous paragraph where it states: > >"The sender may require > more precise feedback from the receiver otherwise it is at risk of > appearin to be understating its ConEx Signals " > >It is not clear to me what it means by appearing=20 >to be understanding its conex signals. OK, I've noted that better explanatory text is=20 needed to describe the problem here. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From acooper@cdt.org Mon Jul 18 10:11: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 B04B821F8640 for ; Mon, 18 Jul 2011 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hV9P44MCtxWw for ; Mon, 18 Jul 2011 10:11:34 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2EA21F85F2 for ; Mon, 18 Jul 2011 10:11:33 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for conex@ietf.org; Mon, 18 Jul 2011 13:11:30 -0400 From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 18:11:28 +0100 Message-Id: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> To: conex@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [conex] "traffic management" 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, 18 Jul 2011 17:11:34 -0000 I've been reviewing draft-ietf-conex-concepts-uses-02 and may send a few = emails about different things. I'm wondering what is meant by "traffic management" as the term is used = in the draft. Sometimes it seems to encompass only actions that = operators might take; other times it seems to also include = endpoint-controlled management of congestion (e.g., in section 3). = Sometimes it seems to be used in a way that is synonymous with = "congestion management"; other times it seems to take on the more = expansive connotation (that I often find used in the UK), encompassing = motivations beyond mitigating congestion (e.g., deferring capacity = investment by reducing peak-hour usage). If what we're really talking about is the management of congestion by = network operators, it might be better to call it "congestion management" = and only use the term when referring to network-based management. If = some more expansive concept is intended, that probably needs to be = clarified. Alissa= From acooper@cdt.org Mon Jul 18 10:58: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 6FB5E21F8B25 for ; Mon, 18 Jul 2011 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imZyeTkLR5eo for ; Mon, 18 Jul 2011 10:58:32 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 244BB21F89B8 for ; Mon, 18 Jul 2011 10:58:27 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 18 Jul 2011 13:58:20 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> Date: Mon, 18 Jul 2011 18:58:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 18 Jul 2011 17:58:33 -0000 Hi Bob, I am finding the organization of the document somewhat confusing. With = the introduction of new text in early sections, it has also become a bit = repetitive in parts. I'll throw out an alternative organization below = with some explanation afterward: 1. Introduction 2. Concepts 3. Definitions 4. Core Use Case: Informing Congestion Management 4.1 History 4.2 Existing Approaches 4.3 Drawbacks of Existing Approaches 4.4 Use Case Description 5. Other Use Cases 5.1 Creating Incentives for Scavenger Transports 5.2 Supporting Intra-Class Quality of Service 5.3 Preventing Congestion Collapse 5.4 Informing Inter-Operator Contracts 5.5 Informing Capacity Provisioning 6. Deployment Arrangements (sub-outline structure as is for now) 7. Commercial Secrecy as a Potential Deployment Barrier 8. Non-Goals 9. Security Considerations 10. IANA Considerations 11. Acknowledgments 12. Contributors 2. Concepts and 3. Definitions -- Right now the only concepts that are = fully teed up in the Concepts section are congestion volume and blame = (which I hope will become accountability or something similar as others = have suggested). So I think it's safe to separate the concepts section = from the definitions section. 4. Core Use Case: Informing Congestion Management -- As of now the = document sort of wavers between emphasizing traffic management (what I'm = calling congestion management) as the key motivating use case and mixing = in some of the other motivating use cases. A clearer separation would = help, I think. I also found the narrative of current sections 3 and 4 = (Traffic Management and Exposing Congestion) to be somewhat disjoint and = repetitive, thus my suggestions for streamlining 4.1-4.4 above. 4.1 maps = to the current intro to section 3; 4.2 maps to the first part of the = current 3.1; 4.3 maps to the second part of the current 3.1 plus the ECN = discussion currently in 4.1; and 4.4 maps to the current 5.1. I think = parts of the intro to the current section 4 are now redundant and other = parts can be fit in to the subsections above as appropriate (e.g., the = LEDBAT discussion could go in the suggested 5.1). 5. Other Use Cases -- This is just the list from the current draft, = although phrased in the active voice. I find the distinction between = consequences and use cases to be of little use; in every case, ConEx = just exposes information and it is up to the operator to act on it, so = in some sense every use case is a consequence. For the "Informing = Traffic Management" case, for example, I don't think the expectation is = that operators will merely be glad to have more information, but they = will actually act on it (perhaps by using an ingress policer as = described). The same can be said for incentivizing scavenger transports: = the operator has to take affirmative steps using the ConEx information = to create the incentives. I don't see the difference between the two. 6. Deployment Arrangements -- I haven't looked at this section in depth = yet so no changes to recommend. 7. Commercial Secrecy as a Potential Deployment Barrier and 8. Non-Goals = -- =46rom the text it seems like dealing with self-congestion is a = non-goal, so it probably can be fit in the non-goals section. And I = agree with earlier reviewers that putting non-goals up front is a = non-starter. If the section is listed in the ToC and previewed at the = end of the introduction, people who are confused will be able to find it = (as opposed to possibly confusing many people by putting it up front = before the actual goals have really been discussed). Alissa On Jul 6, 2011, at 11:57 AM, Bob Briscoe wrote: > ConEx folks, >=20 > The proposed table of contents for draft-02 is pasted at the end. > Please react if you object. There will be controversy, but please try = to recognise that we ought to be converging now. >=20 > Here's the rationale for the changes. >=20 > 2. Definitions -> Concepts >=20 > The "Definitions" section in draft-01 actually introduced the main = concepts, which is goal #1 of this doc. So Concepts is a better section = heading. > Then we've added the much-discussed Misconceptions sub-section = clarifying it's not misconceptions about networking, just about ConEx. >=20 > 5. ConEx Use Cases > Removed one use-case (Accounting for Congestion Volume) but really = just moved it to "Other Use-Cases" so it can be much shorter. >=20 > Under "Other Use-Cases", we propose very brief bullets on each of: > * Preventing congestion collapse > * Accounting for congestion > * Interconnection traffic contracts > * Provisioning capacity >=20 > The idea is to resolve all the to-and-fro about which use-cases should = be in or out, by having a "half-in" category. >=20 > And possibly (controversial!) we could then even add... > * Mitigating flooding attacks >=20 > Note also the change of heading: > 5.3. ConEx for Intra-Class Quality of Service (QoS) > We'll change the story to emphasise that ConEx doesn't replace = Diffserv, but it could handle allocation of resources within a class (ie = bandwidth allocation as opposed to queue scheduling). >=20 > 6. Deployment Arrangements. >=20 > Replaces previous S.5.5. Partial vs. Full Deployment >=20 > It's tough to talk about deployment in a mechanism-neutral way (given = deployment is about deploying mechanisms!). Nonetheless, the idea is to = give a plausible story for how the previously mentioned use-cases would = get incrementally deployed. So it fits in this doc, but it will be = tough. We have summarised stuff about components and incremental = deployment in abstract-mech first (I intend to post proposed new text = for this section to the list shortly). >=20 > 7.2. Self Congestion >=20 > Rather than diving straight into this detailed area early in the = Introduction, we've moved it to where it belongs: under 7. Potential = Issues. >=20 > = /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\= /\/\/\/\/\ > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 > 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . = 5 > 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . = 5 > 2.2. Common Misconceptions about ConEx . . . . . . . . . . . . = 7 > 3. Traffic Management . . . . . . . . . . . . . . . . . . . . . . = 7 > 3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . = 8 > 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . = 9 > 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . = 10 > 5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . = 11 > 5.1. ConEx as a basis for traffic management . . . . . . . . . = 11 > 5.2. ConEx to incentivise scavenger transports . . . . . . . . = 11 > 5.3. ConEx for Intra-Class Quality of Service (QoS) . . . . . . = 12 > 5.4. Other Use-Cases . . . . . . . . . . . . . . . . . . . . . = 13 > 6. Deployment Arrangements . . . . . . . . . . . . . . . . . . . = 13 > 6.1. Deployment Concepts . . . . . . . . . . . . . . . . . . . = 13 > 6.2. Single Receiving Network Scenario . . . . . . . . . . . . = 14 > 6.3. Other Initial Deployment Scenarios . . . . . . . . . . . . = 14 > 7. Potential Issues . . . . . . . . . . . . . . . . . . . . . . . = 14 > 7.1. Congestion as a Commercial Secret . . . . . . . . . . . . = 14 > 7.2. Self Congestion . . . . . . . . . . . . . . . . . . . . . = 15 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 15 > 8.1. Information Security . . . . . . . . . . . . . . . . . . . = 16 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 16 > 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . = 16 > 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 17 > 11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . = 18 > 12. Informative References . . . . . . . . . . . . . . . . . . . . = 18 > Appendix A. Changes from previous drafts (to be removed by > the RFC Editor) . . . . . . . . . . . . . . . . . . . = 19 > = /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\= /\/\/\/\/\ >=20 > Cheers >=20 > Bob (& discussed with Rich as co-editor, but still some uncertainties = - hence asking the list for views) >=20 >=20 > Bob >=20 >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From john@jlc.net Mon Jul 18 11:13: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 F34E221F8B35 for ; Mon, 18 Jul 2011 11:13:26 -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=[AWL=0.000, 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 l7WaSeTpvCfH for ; Mon, 18 Jul 2011 11:13:26 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6309621F89B8 for ; Mon, 18 Jul 2011 11:13:26 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0D28E33C24; Mon, 18 Jul 2011 14:13:26 -0400 (EDT) Date: Mon, 18 Jul 2011 14:13:26 -0400 From: John Leslie To: Alissa Cooper Message-ID: <20110718181325.GB53567@verdi> References: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] "traffic management" 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, 18 Jul 2011 18:13:27 -0000 Alissa Cooper wrote: > > I'm wondering what is meant by "traffic management" as the term is > used in the draft. Sometimes it seems to encompass only actions that > operators might take; That is what I took the term to mean. > other times it seems to also include endpoint-controlled management of > congestion (e.g., in section 3). Hmm... perhaps you mean: " " 3. Traffic Management " " Since 1988 congestion management has been the responsibility of the " end-systems in the Internet architecture. The network signals " congestion to the receiver, the receiver feeds this back to the " sender and the sender is expected to reduce the traffic it sends. " " Nonetheless, since at least when Nagle proposed fair queuing in 1985 " [RFC0970], it has been recognised that end-systems alone cannot be " entrusted with sharing out capacity between themselves. " " Since then capacity has been shared by a mix of traffic management " approaches, partly network-based (weighted round-robin scheduling, " weighted fair queuing, etc) and partly host-based (TCP). This looks like a wordsmithing oversight: I think Bob meant "mix of congestion management and traffic management approches". > Sometimes it seems to be used in a way that is synonymous with > "congestion management"; Could you give examples? > other times it seems to take on the more expansive connotation > (that I often find used in the UK), encompassing motivations beyond > mitigating congestion (e.g., deferring capacity investment by > reducing peak-hour usage). "Traffic Management", as I understand it, is something network operators do, for a variety of reasons -- deferring capacity investment, alas, is inevitably one of them. (It really doesn't help to ridicule it: when the money simply isn't there, or the lead-time is too long, you have to do _something_...) > If what we're really talking about is the management of congestion by > network operators, it might be better to call it "congestion management" > and only use the term when referring to network-based management. I disagree. Network Operators _do_ "traffic management". One of its effects is helping to manage congestion. But they lack tools which are actually directed at congestion-management -- that is, after all, what ConEx is _for_. > If some more expansive concept is intended, that probably needs to > be clarified. I wouldn't call it "more expansive" -- it's more like "the light is so much better here!" -- John Leslie From bob.briscoe@bt.com Mon Jul 18 11:28: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 57AD121F8ABD for ; Mon, 18 Jul 2011 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 0wf5jb2ZQXYG for ; Mon, 18 Jul 2011 11:28:53 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 574B721F8AED for ; Mon, 18 Jul 2011 11:28:53 -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, 18 Jul 2011 19:28:51 +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, 18 Jul 2011 19:28:51 +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 1311013729954; Mon, 18 Jul 2011 19:28:49 +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 p6IISmh9027403; Mon, 18 Jul 2011 19:28:48 +0100 Message-Id: <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jul 2011 19:08:26 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20110713163314.GE2822@verdi> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@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: 18 Jul 2011 18:28:51.0169 (UTC) FILETIME=[8AA9FD10:01CC4578] Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 18 Jul 2011 18:28:55 -0000 John (and Toby, Dirk), OK. I get the message loud and clear; blame is a politically incorrect word - to be avoided. (Rich had already thought it was unsafe language and wishes he had been more forceful against it now). Before addressing your wordsmithing suggestions, can you just confirm that you are not saying we should not use this way of explaining the ConEx concepts (dividing down who is accountable for what), it's just the guilt-laden word blame that is problematic? Now some responses inline... At 17:33 13/07/2011, John Leslie wrote: >Bob Briscoe wrote: > > > > Please give feedback on the proposed new Concepts text below that > > precedes the definitions. > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > 2. Concepts > > > > Despite its central role in network control and management, > > congestion is a remarkably hard concept to define. [Bauer09] > > provides a good academic background. For the purposes of ConEx, the > > definition below focuses on how congestion would be measured, rather > > than precisely what it is. Our definition of congestion is then > > equivalent to the loss probability (or the marking probability if ECN > > is used). > > Seems good... > > > ConEx is essentially about accountability for congestion (or blame in > > crude language). The blame for congestion lies equally between too > > little capacity and too much traffic. On the capacity side, > > congestion itself measures how badly the network provider is to > > blame. On the traffic side, in a shared network, the blame is split > > among all the users. Congestion-volume measures how much of each > > user's traffic is to blame for the congestion. Note that congestion- > > volume is a property of traffic, whereas congestion is a property of > > a link or a path. > > "Blame" is a bad paradigm: once it is introduced, it's hard to avoid >degenerating into arguments of where "blame" belongs. We have up to now >tried to avoid such distractions. Thus, I attempt some wordsmithing: >" >" Congestion is a signal that sender(s) and/or receiver(s) may (or may >" not) be willing to bear a share of the cost of upgrading a congested >" link. But without accountability, the network operator can't quantify >" that willingness. Blaming the network operator is easy, but moot; >" blaming the sender is harder, because you can't tell which sender to >" blame. Jumping from the frying pan into fire! I don't think we should bring cost in at this early stage in the doc. We should keep it as accountability for congestion. We can certainly point to the equivalence of congestion and cost later (e.g. when we talk about provisioning), but we shouldn't turn off some readers who have an allergic reaction to billing and so forth. We can talk about accountability without implying accounting at this stage. >" >" With ConEx accountability, you can quantify which senders intentionally >" sent data over a path known to be congested. While ConEx doesn't >" consider how to assess cost, it does ensure that the needed information >" is right there in the IP packet. Even without any mechanism to assess >" cost, this information better informs any judgment of when to upgrade. I'm afraid this also jumps into the fire from the frying pan. Reason: ditto As Rich said in our offlist conversation about this, ConEx touches a load of different political hot potatoes. We have to somehow describe ConEx without explicitly looking as if we are touching any of them. It might make the doc bland, but we have to do it and we can. > > Congestion-volume is a relatively newly defined metric that is > > central to ConEx. To grasp an intuitive feel for what congestion- > > volume measures, some network operators give you an allowance and > > only count data volume during the peak period against it. This is > > equivalent to counting your congestion-volume by assuming that > > congestion is 100% during the peak period and 0% otherwise. > > This is hard to read. Some possible wordsmithing: >" >" Congestion-volume is a property of traffic central to ConEx. Some >" network operators already do a crude approximation by giving their >" customers a volume allowance during "peak usage". This can be >" thought of as assuming 100% congestion during peak and 0% otherwise. >" We refine that by counting only packets during actual congestion: >" thus assuming 100% congestion for packets marked or dropped, and >" 0% for packets neither marked nor dropped (though in practice we >" need to count packets marked for Congestion-Expected, which lags >" the actual congestion by one Round-Trip-Time). OK. Let's try to use something like this. Did you remove the "relatively newly defined metric" deliberately. This was deliberately in there to gently flag to readers that they might need to turn on their brain for this para: ie "Warning: new concept ahead!". I've realised we don't need to introduce the additional concept of an allowance, we just need to talk about counting. I'm not sure the idea of congestion jumping from 0 to 100% for different packets will help. What do others think? Here's an idea. Would the concept of a weighted average help? Ie. a weighted average of volume sent, where the weights are the levels of congestion when it is sent. As per previous discussion, let's not introduce the time lag discussion at this point in the doc. The new concepts have to come in baby steps. > > The congestion-volume metric is more refined but broadly equivalent, > > and still as simple to measure as the above time-of-day volume. > > Imagine Alice sends 1GB while the loss-probability is a constant > > 0.2%. Then her contribution to congestion (or congestion-volume) is > > 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is 0.1%, > > this adds 3MB to her congestion-volume. Her total contribution to > > congestion is then 2MB+3MB = 5MB. > > > > To measure Alice's congestion-volume no-one has to do all these > > multiplications and additions. It is simply a matter of counting the > > total volume of Alice's traffic that was discarded (a queue with a > > percentage loss involves multiplication inherently). > > I don't think these two paragraphs are needed (but I'm not objecting >to them -- merely suggesting how to get to the point before losing our >readers). OK, I agree the numerical example can go - I was not sure about it at the time. I think we need to keep the essence of the latter para: that this doesn't involve complicated calculations; you just count the volume of dropped or marked packets. > > Finally, there is yet another way to cut the blame for congestion. > > Recall that the level of congestion itself measures the provider's > > blame. However, in an internetwork there are multiple providers. If > > a data centre network with zero congestion is connected to an access > > network and sends traffic over a link with 0.4% loss probability, > > then clearly all the blame for congestion lies with the access > > network. However, at another time, there might be 0.1% congestion > > across the data centre and 0.7% across the access, making 0.8% end- > > to-end congestion across the path. > > I do object to this paragraph. I don't believe it's needed, and I can >see no way to wordsmith it to avoid the "blame" game. > > > In order to apportion blame accordingly, ConEx is designed so that a > > meter at the border can see how much of the congestion is on one side > > or other, termed upstream and downstream congestion. > > Here a simple s/apportion blame accordingly/establish accountability/ >should suffice. If this sentence just stood alone, without the start of the previous para, it would not be clear that we have switched from a property of the traffic back to a property of the path. I agree we could scrub the example with the data centre, but we need something to signpost that we've switched back to congestion, not congestion-volume. And for those who think ConEx is an evil operator-inspired plot, it's important to point out that ConEx equally addresses dividing up the accountability for provisioning, not just accountability for the traffic. In summary, we need to keep something like the first part of the "There is another way to cut the ..." para. And I think it can be rewritten avoiding the blame word. > > If A and B are connected within a chain of more than two networks, A > > attributes all congestion beyond B to B, and vice versa. As far as A > > is concerned, B chooses who to route to, so B takes responsibility > > for its choices. > > I could probably improve on this, but I'm not going to try right now. Can you try to say what is wrong with given text, rather than only re-writing it? It is fine if there are not any problems with the new text. But if there are, before fixing your text, as editors we have to guess what it was you were objecting to by detecting all the differences and reverse-engineering. > > 2.1. Definitions > > > > Congestion: Congestion occurs when any user's traffic suffers > > increased delay, loss or ECN marking as a result of one or more > > network resources becoming overloaded. For the purposes of ConEx, > > the focus is on concrete signals of congestion (ECN and loss), > > therefore delay is set to one side. Congestion is measured as the > > probability of loss or the probability of ECN marking, usually > > expressed as dimensionless percentages. > > I find "delay is set to one side" confusing: I think it would be >better to say "delay is not considered". OK. > Also, I find the "Congestion is measured as" sentence a bit misleading. >ConEx actually is about including a Congestion-Expected signal: exactly >how the sender measures the congestion expected is out-of scope. Eh? We're defining Congestion here, not ConEx. >Perhaps: >" >" Congestion is the probability of loss and/or ECN marking, expressed >" as a dimensionless fraction. I'd be happy with cutting down to such a stark sentence (given we've said earlier we focus on what is practically measurable). But I don't agree with "Congestion is", given we said earlier we're not going to define what congestion is, just how it will be measured. So I don't understand why you don't like "Congestion is measured as"? We have to say this, surely? > > Congestion-volume: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the volume of bytes dropped or marked in a > > given period of time. Conceptually, data volume multiplied by the > > instantaneous congestion each packet of the volume experienced. > > Usually expressed in bytes (or MB, GB, of course). > > Nit: s/Conceptually, data volume/Conceptually it is data volume/ Y > > Congestion-rate: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the instantaneous rate of traffic > > discarded or marked due to congestion. Conceptually, the > > instantaneous bit-rate of the traffic weighted by the > > instantaneous congestion it experiences. Usually expressed in > > b/s. > > This is confusing, and the term isn't used in the document. I suggest >removing the definition. (Otherwise, we need to see how it will be used >and make sure we understand that concept before wordsmithing.) For similar reasons, I considered removing this (during the threads with Georgios & Mikael). But I figured these are definitions for later ConEx use, not just in this doc. When talking about policers, we will need this definition. How about explicitly saying... Congestion-rate: This concept is not needed in the current document but, as it follows naturally from congestion-volume, it is defined here for use in other ConEx documents. For any granularity of traffic (packet, flow, ... > > Upstream Congestion: The accumulated level of congestion experienced > > by a traffic flow thus far, relative to a point along its path. > > In other words, at any point the Upstream Congestion is the > > accmulated level of congestion the traffic flow has experienced as > > it travels from the sender to that point. At the receiver this is > > equivalent to the end-to-end congestion level that (usually) is > > reported back to the sender. > > > > Downstream Congestion: The level of congestion a flow of traffic is > > expected to experience on the remainder of its path. In other > > words, at any point the Downstream Congestion is the level of > > congestion the traffic flow is yet to experience as it travels > > from that point to the receiver. Aka. Rest-of-Path Congestion. > > > > Consumer: A general term representing the contractual entity such as > > a user or business or institution that uses the service of a > > network provider. There is no implication that the contract has > > to be commercial; for instance the consumers of a University or > > enterprise network service would be students or employees and they > > might well be required to comply with some form of contract or > > acceptable use policy. There is also no implication that the > > consumer is necessarily an end-consumer. Where two networks form > > a customer-provider relationship, the term consumer is also > > intended to cover the customer network. > > Personally, I would prefer "customer" to "consumer". "Consumer" >suggests we're talking about the receiver as opposed to the sender. Ug. Customer is too loaded with commercial connotations. ConEx is equally applicable to non-ISP scenarios and we mustn't rule that out with our language. I can't think of another word (neither can the Thesaurus) other than punter :) Do you really think Consumer will get confused with receiver? We could add: "Note: The Consumer could be a sender and/or receiver; it is used in the sense of a consumer of service (not to be confused with a consumer of data)." > > Network provider: (also 'operator'): the term is not confined to > > Internet service providers (ISPs) who run commercial public > > networks but is also intended to generalise to operators of > > enterprise, campus and other networks. > > > > [ConEx-Abstract-Mech] gives further definitions for aspects of ConEx > > to do with protocol mechanisms. > > I'm not sure quite what this means: does it imply that we need to >read abstract-mech for definitions used in this document? (I would >prefer we not ask our readers to do that.) How about: Because ConEx protocol mechanisms are outside this document's scope, mechanism-related definitions can be found in [ConEx-Abstract-Mech]. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Jul 18 11:38: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 DDCF821F8B77 for ; Mon, 18 Jul 2011 11:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 VNqZoAWTe3p5 for ; Mon, 18 Jul 2011 11:38:25 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6021F8AED for ; Mon, 18 Jul 2011 11:38:24 -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); Mon, 18 Jul 2011 19: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); Mon, 18 Jul 2011 19: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 1311014302112; Mon, 18 Jul 2011 19: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 p6IIcLbV027438; Mon, 18 Jul 2011 19:38:21 +0100 Message-Id: <201107181838.p6IIcLbV027438@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jul 2011 19:38:22 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> 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: 18 Jul 2011 18:38:23.0601 (UTC) FILETIME=[DFDC2E10:01CC4579] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 18 Jul 2011 18:38:26 -0000 Alissa, I'll deal with this in small parts. At 18:58 18/07/2011, Alissa Cooper wrote: >2. Concepts and 3. Definitions -- Right now the only concepts that >are fully teed up in the Concepts section are congestion volume and >blame (which I hope will become accountability or something similar >as others have suggested). So I think it's safe to separate the >concepts section from the definitions section. Concepts introduces all of: - congestion - congestion-volume - upstream/downstream congestion all under the framework of cutting accountability different ways. The definitions section is then a formalisation of the prose that precedes it. The addition of provider/consumer is related to the upstream/downstram split, but the link isn't explicitly made (no need IMO). Then, what are you implying about the non-goals/misconceptions subsection, which you've not mentioned? I'm about to go offline, so will continue in the morning... Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Mon Jul 18 11:52: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 57D2521F8562 for ; Mon, 18 Jul 2011 11:52:02 -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=[AWL=0.000, 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 JPLeiW6VEpz8 for ; Mon, 18 Jul 2011 11:52:01 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5A221F8561 for ; Mon, 18 Jul 2011 11:52:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0EE2033C24; Mon, 18 Jul 2011 14:52:01 -0400 (EDT) Date: Mon, 18 Jul 2011 14:52:01 -0400 From: John Leslie To: Alissa Cooper Message-ID: <20110718185200.GC53567@verdi> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 18 Jul 2011 18:52:02 -0000 Alissa Cooper wrote: > > I am finding the organization of the document somewhat confusing. With > the introduction of new text in early sections, it has also become > a bit repetitive in parts. True... :^( > I'll throw out an alternative organization below with some explanation > afterward: > > 1. Introduction > 2. Concepts > 3. Definitions > 4. Core Use Case: Informing Congestion Management > 4.1 History > 4.2 Existing Approaches > 4.3 Drawbacks of Existing Approaches > 4.4 Use Case Description > 5. Other Use Cases > 5.1 Creating Incentives for Scavenger Transports > 5.2 Supporting Intra-Class Quality of Service > 5.3 Preventing Congestion Collapse > 5.4 Informing Inter-Operator Contracts > 5.5 Informing Capacity Provisioning > 6. Deployment Arrangements (sub-outline structure as is for now) > 7. Commercial Secrecy as a Potential Deployment Barrier > 8. Non-Goals > 9. Security Considerations > 10. IANA Considerations > 11. Acknowledgments > 12. Contributors This looks like a promising organization... I can't say whether making such a change at this stage makes sense. I would be willing to help wordsmith if the WGCs decide it does. > 2. Concepts and 3. Definitions -- Right now the only concepts that > are fully teed up in the Concepts section are congestion volume and > blame (which I hope will become accountability or something similar > as others have suggested). So I think it's safe to separate the > concepts section from the definitions section. I certainly agree that _defining_ blame is a super-bad idea! Definitions tend to come first, so that the reader can understand the intended meaning when s/he first encounters the term. Careful wordsmithing can reduce the need for this, and I'd be willing to help. It feels important to get concepts out there first -- especially with so much of our on-list traffic stumbling over them. > 4. Core Use Case: Informing Congestion Management Quibble: I think we _do_ mean "informing traffic management". Network operators are going to do traffic-management anyway, and we can make it work better. > -- As of now the document sort of wavers between emphasizing traffic > management (what I'm calling congestion management) as the key > motivating use case and mixing in some of the other motivating use > cases. A clearer separation would help, I think. I tend to agree. > I also found the narrative of current sections 3 and 4 (Traffic > Management and Exposing Congestion) to be somewhat disjoint and > repetitive, A lot of Section 3 text is new: most of Section 4 is old. Some overlap is inevitable. > thus my suggestions for streamlining 4.1-4.4 above. That seems reasonable, at first blush... > 4.1 maps to the current intro to section 3; > 4.2 maps to the first part of the current 3.1; > 4.3 maps to the second part of the current 3.1 plus the ECN discussion > currently in 4.1; and > 4.4 maps to the current 5.1. (I have to admit that throwing out the Section 4 text preceding 4.1 feels a bit painful -- I don't think it's adequately covered elsewhere.) > I think parts of the intro to the current section 4 are now redundant Hmm... someone else will have to chime in here... This is carefully- crafted text on which I thought we had consensus. Carving it up into pieces, IMHO, endangers the consensus. > and other parts can be fit in to the subsections above as appropriate > (e.g., the LEDBAT discussion could go in the suggested 5.1). To me, LEDBAT isn't the point -- the point is that current traffic management disincents good behavior. This feels like something which belongs earlier than a secondary use-case. > 5. Other Use Cases -- This is just the list from the current draft, > although phrased in the active voice. Active-voice is good... > I find the distinction between consequences and use cases to be of > little use; in every case, ConEx just exposes information and it is > up to the operator to act on it, so in some sense every use case is > a > consequence. I think I agree. > For the "Informing Traffic Management" case, for example, I don't > think the expectation is that operators will merely be glad to have > more information, but they will actually act on it (perhaps by using > an ingress policer as described). That's by no means the only way to act on it... > The same can be said for incentivizing scavenger transports: the > operator has to take affirmative steps using the ConEx information > to create the incentives. I don't see the difference between the two. It's no so much a difference between use -- it's a difference in motivation to use ConEx information. I think the uses deserve separate billing... > 6. Deployment Arrangements -- I haven't looked at this section in > depth yet so no changes to recommend. Certainly incremental-deployment is an essential feature -- but I don't want to talk details here yet either. > 7. Commercial Secrecy as a Potential Deployment Barrier and > 8. Non-Goals -- From the text it seems like dealing with self- > congestion is a non-goal, so it probably can be fit in the non-goals > section. That doesn't feel quite right. Self-congestion differs in that the network operator can do little to help -- but it may look no different to the application self-congesting. The same tools which a network operator might use to act on ConEx information could be deployed by users before the Internet Ingress. Also, to some degree, self-congestion can result from a receiver requesting too much; and there is quite a bit network operators could do there. > And I agree with earlier reviewers that putting non-goals up front > is a non-starter. If the section is listed in the ToC and previewed > at the end of the introduction, people who are confused will be able > to find it (as opposed to possibly confusing many people by putting > it up front before the actual goals have really been discussed). +1 -- John Leslie From john@jlc.net Mon Jul 18 12:35: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 4B64B22800E for ; Mon, 18 Jul 2011 12:35:38 -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=[AWL=0.000, 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 u3yyaRPPm287 for ; Mon, 18 Jul 2011 12:35:37 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE421F8754 for ; Mon, 18 Jul 2011 12:35:36 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A134B33C26; Mon, 18 Jul 2011 15:35:36 -0400 (EDT) Date: Mon, 18 Jul 2011 15:35:36 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110718193536.GD53567@verdi> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 18 Jul 2011 19:35:38 -0000 Bob Briscoe wrote: > At 17:33 13/07/2011, John Leslie wrote: > >> "Blame" is a bad paradigm: once it is introduced, it's hard to avoid >> degenerating into arguments of where "blame" belongs. We have up to now >> tried to avoid such distractions. Thus, I attempt some wordsmithing: (It's not unusual for the first wordsmithing attempt to fail...) >>" Congestion is a signal that sender(s) and/or receiver(s) may (or may >>" not) be willing to bear a share of the cost of upgrading a congested >>" link. But without accountability, the network operator can't quantify >>" that willingness. Blaming the network operator is easy, but moot; >>" blaming the sender is harder, because you can't tell which sender to >>" blame. > > Jumping from the frying pan into fire! I don't think we should bring > cost in at this early stage in the doc. We should keep it as > accountability for congestion. Nonetheless, congestion _is_ a signal of something like that; and ConEx intends to make an even-more-useful signal visible at the network layer. Retreating in horror at the C-word (cost) doesn't help. > We can certainly point to the equivalence of congestion and cost > later (e.g. when we talk about provisioning), but we shouldn't turn > off some readers who have an allergic reaction to billing and so > forth. We can talk about accountability without implying accounting > at this stage. Careful, there: "accountability" already raises some of the C-word hackles. ;^) >>" With ConEx accountability, you can quantify which senders intentionally >>" sent data over a path known to be congested. This _is_ a central point (though I must agree it's probably too early to introduce it). >>" While ConEx doesn't consider how to assess cost, it does ensure that >>" the needed information is right there in the IP packet. Even without >>" any mechanism to assess cost, this information better informs any >>" judgment of when to upgrade. > > I'm afraid this also jumps into the fire from the frying pan. > Reason: ditto Quite possibly none of your words belong so early in the document either. Reason: ditto. > As Rich said in our offlist conversation about this, ConEx touches a > load of different political hot potatoes. We have to somehow describe > ConEx without explicitly looking as if we are touching any of them. > It might make the doc bland, but we have to do it and we can. We "want to avoid" that, yes. But we do need to get across the idea that essential information is missing. Where I was trying to go is that the mere fact that a sender _deliberately_ sends data down a congested path is useful information to inform network upgrade decisions, even without any cost-sharing mechanism. >>" Congestion-volume is a property of traffic central to ConEx. Some >>" network operators already do a crude approximation by giving their >>" customers a volume allowance during "peak usage". This can be >>" thought of as assuming 100% congestion during peak and 0% otherwise. >>" We refine that by counting only packets during actual congestion: >>" thus assuming 100% congestion for packets marked or dropped, and >>" 0% for packets neither marked nor dropped (though in practice we >>" need to count packets marked for Congestion-Expected, which lags >>" the actual congestion by one Round-Trip-Time). > > OK. Let's try to use something like this. > > Did you remove the "relatively newly defined metric" deliberately. Well, yes... > This was deliberately in there to gently flag to readers that they > might need to turn on their brain for this para: ie "Warning: new > concept ahead!". Exactly: when warned, readers tend to turn their brain off; when they merely encounter a new idea, they tend to forget they saw it. Big difference! When they run into the new idea again, in the latter case, it comes with a patina of familiarity. > I've realised we don't need to introduce the additional concept of an > allowance, we just need to talk about counting. Probably a good idea. > I'm not sure the idea of congestion jumping from 0 to 100% for > different packets will help. What do others think? Here's an idea. > Would the concept of a weighted average help? Ie. a weighted average > of volume sent, where the weights are the levels of congestion when it > is sent. I found it helpful to contrast binary counting of volume with binary counting of congestion -- and didn't feel the need to go into weighed anything (which does frighten a number of readers). > As per previous discussion, let's not introduce the time lag > discussion at this point in the doc. The new concepts have to come in > baby steps. I think it's important for _us_ to remember the time-lag -- but I don't think it's necessary to bother the reader with it, least of all early in the document. >>> >>> To measure Alice's congestion-volume no-one has to do all these >>> multiplications and additions. It is simply a matter of counting the >>> total volume of Alice's traffic that was discarded (a queue with a >>> percentage loss involves multiplication inherently). >> >> I don't think these two paragraphs are needed... > > OK, I agree the numerical example can go - I was not sure about it at the > time. > > I think we need to keep the essence of the latter para: that this > doesn't involve complicated calculations; you just count the volume > of dropped or marked packets. The question is how early we need to get into mechanism... >> > I agree we could scrub the example with the data centre, but we need > something to signpost that we've switched back to congestion, not > congestion-volume. And for those who think ConEx is an evil > operator-inspired plot, it's important to point out that ConEx > equally addresses dividing up the accountability for provisioning, > not just accountability for the traffic. Better, we could wordsmith so we don't need to switch back and forth. >>> If A and B are connected within a chain of more than two networks, A >>> attributes all congestion beyond B to B, and vice versa. As far as A >>> is concerned, B chooses who to route to, so B takes responsibility >>> for its choices. >> >> I could probably improve on this, but I'm not going to try right now. > > Can you try to say what is wrong with given text, rather than only > re-writing it? It is fine if there are not any problems with the new > text. But if there are, before fixing your text, as editors we have > to guess what it was you were objecting to by detecting all the > differences and reverse-engineering. It's describing mechanism, and the mechanism is confusing to the casual reader. Also, it goes _way_ beyond the limited deployment we are chartered to consider. I doubt it's even needed in the document at all. >>> 2.1. Definitions >>> Congestion is measured as the >>> probability of loss or the probability of ECN marking, usually >>> expressed as dimensionless percentages. > >> Also, I find the "Congestion is measured as" sentence a bit misleading. >> ConEx actually is about including a Congestion-Expected signal: exactly >> how the sender measures the congestion expected is out-of scope. > > Eh? We're defining Congestion here, not ConEx. But in fact, our definition is intentionally vague... >> Perhaps: >>" >>" Congestion is the probability of loss and/or ECN marking, expressed >>" as a dimensionless fraction. > > I'd be happy with cutting down to such a stark sentence (given we've > said earlier we focus on what is practically measurable). But I don't > agree with "Congestion is", given we said earlier we're not going to > define what congestion is, just how it will be measured. So I don't > understand why you don't like "Congestion is measured as"? We have to > say this, surely? I objected to the _sentence_ -- not the words. You're welcome to say "Congestion is measured as; but it's not a definition, it's a description. "Congestion is defined as", or "Here we define congestion as" would be more accurate wording. >>> Congestion-rate: For any granularity of traffic (packet, flow, >>> aggregate, link, etc.), the instantaneous rate of traffic >>> discarded or marked due to congestion. Conceptually, the >>> instantaneous bit-rate of the traffic weighted by the >>> instantaneous congestion it experiences. Usually expressed in >>> b/s. >> >> This is confusing, and the term isn't used in the document. I suggest >> removing the definition. (Otherwise, we need to see how it will be used >> and make sure we understand that concept before wordsmithing.) > > For similar reasons, I considered removing this (during the threads > with Georgios & Mikael). But I figured these are definitions for > later ConEx use, not just in this doc. When talking about policers, > we will need this definition. Future documents can always refer to future definitions... > How about explicitly saying... > > Congestion-rate: This concept is not needed in the current > document but, as it follows naturally from congestion-volume, it is > defined here for use in other ConEx documents. For any granularity of > traffic (packet, flow, ... Unnecessarily confusing to the casual reader. >>> Consumer: A general term representing the contractual entity such as >>> a user or business or institution that uses the service of a >>> network provider. There is no implication that the contract has >>> to be commercial; for instance the consumers of a University or >>> enterprise network service would be students or employees and they >>> might well be required to comply with some form of contract or >>> acceptable use policy. There is also no implication that the >>> consumer is necessarily an end-consumer. Where two networks form >>> a customer-provider relationship, the term consumer is also >>> intended to cover the customer network. >> >> Personally, I would prefer "customer" to "consumer". "Consumer" >> suggests we're talking about the receiver as opposed to the sender. > > Ug. Customer is too loaded with commercial connotations. ConEx is > equally applicable to non-ISP scenarios and we mustn't rule that out > with our language. I think you're way over-sensitive here. "Customer" contains no implications of what the contractual relationship is -- or even if a contract is recognized to exist. And "consumer" does bring confusion about sender vs. receiver. > I can't think of another word (neither can the Thesaurus) other than > punter :) > > Do you really think Consumer will get confused with receiver? > We could add: > > "Note: The Consumer could be a sender and/or receiver; it is used in > the sense of a consumer of service (not to be confused with a > consumer of data)." That would help -- if you're unwilling to go back to "customer". >>> [ConEx-Abstract-Mech] gives further definitions for aspects of ConEx >>> to do with protocol mechanisms. >> >> I'm not sure quite what this means: does it imply that we need to >> read abstract-mech for definitions used in this document? (I would >> prefer we not ask our readers to do that.) > > How about: > Because ConEx protocol mechanisms are outside this document's > scope, mechanism-related definitions can be found in > [ConEx-Abstract-Mech]. Much clearer! -- John Leslie From toby@moncaster.com Mon Jul 18 13:28: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 B6FBD228011 for ; Mon, 18 Jul 2011 13:28:39 -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 6aiXT5leVKXd for ; Mon, 18 Jul 2011 13:28:38 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id C111C22800E for ; Mon, 18 Jul 2011 13:28:37 -0700 (PDT) Received: from TobysHP (host86-132-207-13.range86-132.btcentralplus.com [86.132.207.13]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MYcc6-1Qwk2S3fzW-00Uzqp; Mon, 18 Jul 2011 22:28:35 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'John Leslie'" References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> In-Reply-To: <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> Date: Mon, 18 Jul 2011 21:28:34 +0100 Message-ID: <002d01cc4589$44e18c10$cea4a430$@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: AcxFeI/tl7XxsZRIQmuZ7sk8OPlmWwAEEUZw Content-Language: en-gb X-Provags-ID: V02:K0:cY3slq39/4tk3s+6Obzb5REufRnJJRf+mNekL8S5iNG ZoxFMlR3LSge044DHKqjF7j/1df0CEhFHQtTgDd0Ko0dF3arrM TDxZlaMYL8Zkd6gSg1vLNTbekOd+80EsNfV8nopZDdBFvl8yeC SNexwCzGd7MHAB8ZwExyWbgdW7VB79LlEN5RsUjA7nwwuP1xhv QLVnRkCNPtiTPBBpISz8W1f6cZSuhuHhSSwEMplzjI= Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 18 Jul 2011 20:28:39 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: 18 July 2011 19:08 > To: John Leslie > Cc: conex@ietf.org > Subject: Re: [conex] New concepts text in draft-ietf-conex-concepts- > uses > > John (and Toby, Dirk), > > OK. I get the message loud and clear; blame is a politically > incorrect word - to be avoided. (Rich had already thought it was > unsafe language and wishes he had been more forceful against it now). > > Before addressing your wordsmithing suggestions, can you just confirm > that you are not saying we should not use this way of explaining the > ConEx concepts (dividing down who is accountable for what), it's just > the guilt-laden word blame that is problematic? Speaking for myself I was just a little concerned that the document is getting too political (or at least opening itself up to wilful misinterpretation). I'm hoping to get time to read through it properly when I am actually awake (rather than the semi-comatose state my daily commute leaves me in), then I will be able to make some more constructive suggestions... At the moment I have no objections to your actual approach to explaining this Toby > > Now some responses inline... > > > At 17:33 13/07/2011, John Leslie wrote: > >Bob Briscoe wrote: > > > > > > Please give feedback on the proposed new Concepts text below that > > > precedes the definitions. > > > > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > \ > > > 2. Concepts > > > > > > Despite its central role in network control and management, > > > congestion is a remarkably hard concept to define. [Bauer09] > > > provides a good academic background. For the purposes of ConEx, > the > > > definition below focuses on how congestion would be measured, > rather > > > than precisely what it is. Our definition of congestion is then > > > equivalent to the loss probability (or the marking probability > if ECN > > > is used). > > > > Seems good... > > > > > ConEx is essentially about accountability for congestion (or > blame in > > > crude language). The blame for congestion lies equally between > too > > > little capacity and too much traffic. On the capacity side, > > > congestion itself measures how badly the network provider is to > > > blame. On the traffic side, in a shared network, the blame is > split > > > among all the users. Congestion-volume measures how much of > each > > > user's traffic is to blame for the congestion. Note that > congestion- > > > volume is a property of traffic, whereas congestion is a > property of > > > a link or a path. > > > > "Blame" is a bad paradigm: once it is introduced, it's hard to > avoid > >degenerating into arguments of where "blame" belongs. We have up to > now > >tried to avoid such distractions. Thus, I attempt some wordsmithing: > >" > >" Congestion is a signal that sender(s) and/or receiver(s) may (or may > >" not) be willing to bear a share of the cost of upgrading a congested > >" link. But without accountability, the network operator can't > quantify > >" that willingness. Blaming the network operator is easy, but moot; > >" blaming the sender is harder, because you can't tell which sender to > >" blame. > > Jumping from the frying pan into fire! I don't think we should bring > cost in at this early stage in the doc. We should keep it as > accountability for congestion. > > We can certainly point to the equivalence of congestion and cost > later (e.g. when we talk about provisioning), but we shouldn't turn > off some readers who have an allergic reaction to billing and so > forth. We can talk about accountability without implying accounting > at this stage. > > >" > >" With ConEx accountability, you can quantify which senders > intentionally > >" sent data over a path known to be congested. While ConEx doesn't > >" consider how to assess cost, it does ensure that the needed > information > >" is right there in the IP packet. Even without any mechanism to > assess > >" cost, this information better informs any judgment of when to > upgrade. > > I'm afraid this also jumps into the fire from the frying pan. Reason: > ditto > > As Rich said in our offlist conversation about this, ConEx touches a > load of different political hot potatoes. We have to somehow describe > ConEx without explicitly looking as if we are touching any of them. > It might make the doc bland, but we have to do it and we can. > > > > > Congestion-volume is a relatively newly defined metric that is > > > central to ConEx. To grasp an intuitive feel for what > congestion- > > > volume measures, some network operators give you an allowance > and > > > only count data volume during the peak period against it. This > is > > > equivalent to counting your congestion-volume by assuming that > > > congestion is 100% during the peak period and 0% otherwise. > > > > This is hard to read. Some possible wordsmithing: > >" > >" Congestion-volume is a property of traffic central to ConEx. Some > >" network operators already do a crude approximation by giving their > >" customers a volume allowance during "peak usage". This can be > >" thought of as assuming 100% congestion during peak and 0% otherwise. > >" We refine that by counting only packets during actual congestion: > >" thus assuming 100% congestion for packets marked or dropped, and > >" 0% for packets neither marked nor dropped (though in practice we > >" need to count packets marked for Congestion-Expected, which lags > >" the actual congestion by one Round-Trip-Time). > > OK. Let's try to use something like this. > > Did you remove the "relatively newly defined metric" deliberately. > This was deliberately in there to gently flag to readers that they > might need to turn on their brain for this para: ie "Warning: new > concept ahead!". > > I've realised we don't need to introduce the additional concept of an > allowance, we just need to talk about counting. > > I'm not sure the idea of congestion jumping from 0 to 100% for > different packets will help. What do others think? Here's an idea. > Would the concept of a weighted average help? Ie. a weighted average > of volume sent, where the weights are the levels of congestion when it > is sent. > > As per previous discussion, let's not introduce the time lag > discussion at this point in the doc. The new concepts have to come in > baby steps. > > > > > The congestion-volume metric is more refined but broadly > equivalent, > > > and still as simple to measure as the above time-of-day volume. > > > Imagine Alice sends 1GB while the loss-probability is a constant > > > 0.2%. Then her contribution to congestion (or congestion- > volume) is > > > 1GB x 0.2% = 2MB. If she then sends 3GB while congestion is > 0.1%, > > > this adds 3MB to her congestion-volume. Her total contribution > to > > > congestion is then 2MB+3MB = 5MB. > > > > > > To measure Alice's congestion-volume no-one has to do all these > > > multiplications and additions. It is simply a matter of > counting the > > > total volume of Alice's traffic that was discarded (a queue with > a > > > percentage loss involves multiplication inherently). > > > > I don't think these two paragraphs are needed (but I'm not > objecting > >to them -- merely suggesting how to get to the point before losing our > >readers). > > OK, I agree the numerical example can go - I was not sure about it at > the time. > > I think we need to keep the essence of the latter para: that this > doesn't involve complicated calculations; you just count the volume > of dropped or marked packets. > > > > > Finally, there is yet another way to cut the blame for > congestion. > > > Recall that the level of congestion itself measures the > provider's > > > blame. However, in an internetwork there are multiple > providers. If > > > a data centre network with zero congestion is connected to an > access > > > network and sends traffic over a link with 0.4% loss > probability, > > > then clearly all the blame for congestion lies with the access > > > network. However, at another time, there might be 0.1% > congestion > > > across the data centre and 0.7% across the access, making 0.8% > end- > > > to-end congestion across the path. > > > > I do object to this paragraph. I don't believe it's needed, and I > can > >see no way to wordsmith it to avoid the "blame" game. > > > > > In order to apportion blame accordingly, ConEx is designed so > that a > > > meter at the border can see how much of the congestion is on one > side > > > or other, termed upstream and downstream congestion. > > > > Here a simple s/apportion blame accordingly/establish > accountability/ > >should suffice. > > If this sentence just stood alone, without the start of the previous > para, it would not be clear that we have switched from a property of > the traffic back to a property of the path. > > I agree we could scrub the example with the data centre, but we need > something to signpost that we've switched back to congestion, not > congestion-volume. And for those who think ConEx is an evil > operator-inspired plot, it's important to point out that ConEx > equally addresses dividing up the accountability for provisioning, > not just accountability for the traffic. > > In summary, we need to keep something like the first part of the > "There is another way to cut the ..." para. And I think it can be > rewritten avoiding the blame word. > > > > > > If A and B are connected within a chain of more than two > networks, A > > > attributes all congestion beyond B to B, and vice versa. As far > as A > > > is concerned, B chooses who to route to, so B takes > responsibility > > > for its choices. > > > > I could probably improve on this, but I'm not going to try right > now. > > Can you try to say what is wrong with given text, rather than only > re-writing it? It is fine if there are not any problems with the new > text. But if there are, before fixing your text, as editors we have > to guess what it was you were objecting to by detecting all the > differences and reverse-engineering. > > > > > 2.1. Definitions > > > > > > Congestion: Congestion occurs when any user's traffic suffers > > > increased delay, loss or ECN marking as a result of one or > more > > > network resources becoming overloaded. For the purposes of > ConEx, > > > the focus is on concrete signals of congestion (ECN and > loss), > > > therefore delay is set to one side. Congestion is measured > as the > > > probability of loss or the probability of ECN marking, > usually > > > expressed as dimensionless percentages. > > > > I find "delay is set to one side" confusing: I think it would be > >better to say "delay is not considered". > > OK. > > > > Also, I find the "Congestion is measured as" sentence a bit > misleading. > >ConEx actually is about including a Congestion-Expected signal: > exactly > >how the sender measures the congestion expected is out-of scope. > > Eh? We're defining Congestion here, not ConEx. > > >Perhaps: > >" > >" Congestion is the probability of loss and/or ECN marking, expressed > >" as a dimensionless fraction. > > I'd be happy with cutting down to such a stark sentence (given we've > said earlier we focus on what is practically measurable). But I don't > agree with "Congestion is", given we said earlier we're not going to > define what congestion is, just how it will be measured. So I don't > understand why you don't like "Congestion is measured as"? We have to > say this, surely? > > > > > Congestion-volume: For any granularity of traffic (packet, > flow, > > > aggregate, link, etc.), the volume of bytes dropped or marked > in a > > > given period of time. Conceptually, data volume multiplied > by the > > > instantaneous congestion each packet of the volume > experienced. > > > Usually expressed in bytes (or MB, GB, of course). > > > > Nit: s/Conceptually, data volume/Conceptually it is data volume/ > > Y > > > > > Congestion-rate: For any granularity of traffic (packet, flow, > > > aggregate, link, etc.), the instantaneous rate of traffic > > > discarded or marked due to congestion. Conceptually, the > > > instantaneous bit-rate of the traffic weighted by the > > > instantaneous congestion it experiences. Usually expressed > in > > > b/s. > > > > This is confusing, and the term isn't used in the document. I > suggest > >removing the definition. (Otherwise, we need to see how it will be > used > >and make sure we understand that concept before wordsmithing.) > > For similar reasons, I considered removing this (during the threads > with Georgios & Mikael). But I figured these are definitions for > later ConEx use, not just in this doc. When talking about policers, > we will need this definition. > > How about explicitly saying... > > Congestion-rate: This concept is not needed in the current > document but, as it follows naturally from congestion-volume, it is > defined here for use in other ConEx documents. For any granularity of > traffic (packet, flow, ... > > > > > > Upstream Congestion: The accumulated level of congestion > experienced > > > by a traffic flow thus far, relative to a point along its > path. > > > In other words, at any point the Upstream Congestion is the > > > accmulated level of congestion the traffic flow has > experienced as > > > it travels from the sender to that point. At the receiver > this is > > > equivalent to the end-to-end congestion level that (usually) > is > > > reported back to the sender. > > > > > > Downstream Congestion: The level of congestion a flow of > traffic is > > > expected to experience on the remainder of its path. In > other > > > words, at any point the Downstream Congestion is the level of > > > congestion the traffic flow is yet to experience as it > travels > > > from that point to the receiver. Aka. Rest-of-Path > Congestion. > > > > > > Consumer: A general term representing the contractual entity > such as > > > a user or business or institution that uses the service of a > > > network provider. There is no implication that the contract > has > > > to be commercial; for instance the consumers of a University > or > > > enterprise network service would be students or employees and > they > > > might well be required to comply with some form of contract > or > > > acceptable use policy. There is also no implication that the > > > consumer is necessarily an end-consumer. Where two networks > form > > > a customer-provider relationship, the term consumer is also > > > intended to cover the customer network. > > > > Personally, I would prefer "customer" to "consumer". "Consumer" > >suggests we're talking about the receiver as opposed to the sender. > > Ug. Customer is too loaded with commercial connotations. ConEx is > equally applicable to non-ISP scenarios and we mustn't rule that out > with our language. > > I can't think of another word (neither can the Thesaurus) other than > punter :) > > Do you really think Consumer will get confused with receiver? We could > add: > > "Note: The Consumer could be a sender and/or receiver; it is used in > the sense of a consumer of service (not to be confused with a > consumer of data)." > > > > > Network provider: (also 'operator'): the term is not confined > to > > > Internet service providers (ISPs) who run commercial public > > > networks but is also intended to generalise to operators of > > > enterprise, campus and other networks. > > > > > > [ConEx-Abstract-Mech] gives further definitions for aspects of > ConEx > > > to do with protocol mechanisms. > > > > I'm not sure quite what this means: does it imply that we need to > >read abstract-mech for definitions used in this document? (I would > >prefer we not ask our readers to do that.) > > How about: > Because ConEx protocol mechanisms are outside this document's > scope, mechanism-related definitions can be found in [ConEx-Abstract- > Mech]. > > > Bob > > > >-- > >John Leslie > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Mon Jul 18 13:37: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 21DA121F8B03 for ; Mon, 18 Jul 2011 13:37:46 -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 FG886iiMDVc3 for ; Mon, 18 Jul 2011 13:37:45 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id C654821F8B01 for ; Mon, 18 Jul 2011 13:37:44 -0700 (PDT) Received: from TobysHP (host86-132-207-13.range86-132.btcentralplus.com [86.132.207.13]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lz0c4-1RVFy83o9I-014fZL; Mon, 18 Jul 2011 22:37:41 +0200 From: "Toby Moncaster" To: "'John Leslie'" , "'Bob Briscoe'" References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> In-Reply-To: <20110718193536.GD53567@verdi> Date: Mon, 18 Jul 2011 21:37:40 +0100 Message-ID: <002e01cc458a$8a39f800$9eade800$@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: AcxFgeFOo4cVHf0LSUaavbV2Gy1I8gAB2pTg Content-Language: en-gb X-Provags-ID: V02:K0:iXqeMRTD3NTBVjb102YqaWqGgl3wUhkk+WRcpn8biPx qo8DKmvIKO+uAy8Opph/gItfweiHDJiN2mE+Xs8t95hBcdHcab D/vRdXJ2x2ZKPFyLzDCszANSAXNzgowFebB/LMBEL/JBLmRop7 Ji6l3k/Uw+X3sQnY2x0ay/+wEIn0z+7ZgNQxBNHVYpZOFp3ZDF f50kkfjYTQogcS365EaIvm3Bj8TThz7lr41sa+R7e8= Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 18 Jul 2011 20:37:46 -0000 I have only skim read this and the following is rather a rambling chain of consciousness. I think at some stage we have to grab the bull by the horns and talk about cost, however as things stand we need to treat this aspect really cautiously. And we have to accept that readers are bright enough to make the link between accountability and cost... Where they are struggling is in understanding the difference between the variable cost (congestion) and the fixed costs (infrastructure) - they are worried that ConEx is just opening the door to allowing ISPs to charge for any and all congestion thus coining money. There is no easy way through this. I think we need to somehow provide a reasonable analogy, but I'm too tired to think of one for now. One part of me has always wanted to describe all this in terms if equity and equitable shares of the network, but that is also open to misinterpretation. Perhaps what we have to get across is that we are coming up with a way to apportion responsibility between operators and users. Make more use of the Tragedy of the Commons argument, using a suitable analogy to show why such a world is unsustainable without either heavy handed intervention by ISPs or huge investment (at a time when investment is not high on the agenda) or by using ConEx. Hope at least some of this makes sense :) Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 18 July 2011 20:36 > To: Bob Briscoe > Cc: conex@ietf.org > Subject: Re: [conex] New concepts text in draft-ietf-conex-concepts- > uses > > Bob Briscoe wrote: > > At 17:33 13/07/2011, John Leslie wrote: > > > >> "Blame" is a bad paradigm: once it is introduced, it's hard to avoid > >> degenerating into arguments of where "blame" belongs. We have up to > now > >> tried to avoid such distractions. Thus, I attempt some wordsmithing: > > (It's not unusual for the first wordsmithing attempt to fail...) > > >>" Congestion is a signal that sender(s) and/or receiver(s) may (or > may > >>" not) be willing to bear a share of the cost of upgrading a > congested > >>" link. But without accountability, the network operator can't > quantify > >>" that willingness. Blaming the network operator is easy, but moot; > >>" blaming the sender is harder, because you can't tell which sender > to > >>" blame. > > > > Jumping from the frying pan into fire! I don't think we should bring > > cost in at this early stage in the doc. We should keep it as > > accountability for congestion. > > Nonetheless, congestion _is_ a signal of something like that; and > ConEx intends to make an even-more-useful signal visible at the > network layer. Retreating in horror at the C-word (cost) doesn't help. > > > We can certainly point to the equivalence of congestion and cost > > later (e.g. when we talk about provisioning), but we shouldn't turn > > off some readers who have an allergic reaction to billing and so > > forth. We can talk about accountability without implying accounting > > at this stage. > > Careful, there: "accountability" already raises some of the C-word > hackles. ;^) > > >>" With ConEx accountability, you can quantify which senders > intentionally > >>" sent data over a path known to be congested. > > This _is_ a central point (though I must agree it's probably too > early > to introduce it). > > >>" While ConEx doesn't consider how to assess cost, it does ensure > that > >>" the needed information is right there in the IP packet. Even > without > >>" any mechanism to assess cost, this information better informs any > >>" judgment of when to upgrade. > > > > I'm afraid this also jumps into the fire from the frying pan. > > Reason: ditto > > Quite possibly none of your words belong so early in the document > either. Reason: ditto. > > > As Rich said in our offlist conversation about this, ConEx touches a > > load of different political hot potatoes. We have to somehow describe > > ConEx without explicitly looking as if we are touching any of them. > > It might make the doc bland, but we have to do it and we can. > > We "want to avoid" that, yes. But we do need to get across the idea > that essential information is missing. Where I was trying to go is that > the mere fact that a sender _deliberately_ sends data down a congested > path is useful information to inform network upgrade decisions, even > without any cost-sharing mechanism. > > >>" Congestion-volume is a property of traffic central to ConEx. Some > >>" network operators already do a crude approximation by giving their > >>" customers a volume allowance during "peak usage". This can be > >>" thought of as assuming 100% congestion during peak and 0% > otherwise. > >>" We refine that by counting only packets during actual congestion: > >>" thus assuming 100% congestion for packets marked or dropped, and > >>" 0% for packets neither marked nor dropped (though in practice we > >>" need to count packets marked for Congestion-Expected, which lags > >>" the actual congestion by one Round-Trip-Time). > > > > OK. Let's try to use something like this. > > > > Did you remove the "relatively newly defined metric" deliberately. > > Well, yes... > > > This was deliberately in there to gently flag to readers that they > > might need to turn on their brain for this para: ie "Warning: new > > concept ahead!". > > Exactly: when warned, readers tend to turn their brain off; when > they merely encounter a new idea, they tend to forget they saw it. > Big difference! When they run into the new idea again, in the latter > case, it comes with a patina of familiarity. > > > I've realised we don't need to introduce the additional concept of an > > allowance, we just need to talk about counting. > > Probably a good idea. > > > I'm not sure the idea of congestion jumping from 0 to 100% for > > different packets will help. What do others think? Here's an idea. > > Would the concept of a weighted average help? Ie. a weighted average > > of volume sent, where the weights are the levels of congestion when > it > > is sent. > > I found it helpful to contrast binary counting of volume with binary > counting of congestion -- and didn't feel the need to go into weighed > anything (which does frighten a number of readers). > > > As per previous discussion, let's not introduce the time lag > > discussion at this point in the doc. The new concepts have to come in > > baby steps. > > I think it's important for _us_ to remember the time-lag -- but I > don't think it's necessary to bother the reader with it, least of all > early in the document. > > >>> > >>> To measure Alice's congestion-volume no-one has to do all these > >>> multiplications and additions. It is simply a matter of counting > the > >>> total volume of Alice's traffic that was discarded (a queue with a > >>> percentage loss involves multiplication inherently). > >> > >> I don't think these two paragraphs are needed... > > > > OK, I agree the numerical example can go - I was not sure about it at > the > > time. > > > > I think we need to keep the essence of the latter para: that this > > doesn't involve complicated calculations; you just count the volume > > of dropped or marked packets. > > The question is how early we need to get into mechanism... > > >> > > I agree we could scrub the example with the data centre, but we need > > something to signpost that we've switched back to congestion, not > > congestion-volume. And for those who think ConEx is an evil > > operator-inspired plot, it's important to point out that ConEx > > equally addresses dividing up the accountability for provisioning, > > not just accountability for the traffic. > > Better, we could wordsmith so we don't need to switch back and > forth. > > >>> If A and B are connected within a chain of more than two networks, > A > >>> attributes all congestion beyond B to B, and vice versa. As far > as A > >>> is concerned, B chooses who to route to, so B takes responsibility > >>> for its choices. > >> > >> I could probably improve on this, but I'm not going to try right > now. > > > > Can you try to say what is wrong with given text, rather than only > > re-writing it? It is fine if there are not any problems with the new > > text. But if there are, before fixing your text, as editors we have > > to guess what it was you were objecting to by detecting all the > > differences and reverse-engineering. > > It's describing mechanism, and the mechanism is confusing to the > casual reader. Also, it goes _way_ beyond the limited deployment we > are chartered to consider. I doubt it's even needed in the document > at all. > > >>> 2.1. Definitions > >>> Congestion is measured as the > >>> probability of loss or the probability of ECN marking, usually > >>> expressed as dimensionless percentages. > > > >> Also, I find the "Congestion is measured as" sentence a bit > misleading. > >> ConEx actually is about including a Congestion-Expected signal: > exactly > >> how the sender measures the congestion expected is out-of scope. > > > > Eh? We're defining Congestion here, not ConEx. > > But in fact, our definition is intentionally vague... > > >> Perhaps: > >>" > >>" Congestion is the probability of loss and/or ECN marking, expressed > >>" as a dimensionless fraction. > > > > I'd be happy with cutting down to such a stark sentence (given we've > > said earlier we focus on what is practically measurable). But I don't > > agree with "Congestion is", given we said earlier we're not going to > > define what congestion is, just how it will be measured. So I don't > > understand why you don't like "Congestion is measured as"? We have to > > say this, surely? > > I objected to the _sentence_ -- not the words. You're welcome to say > "Congestion is measured as; but it's not a definition, it's a > description. > "Congestion is defined as", or "Here we define congestion as" would be > more accurate wording. > > >>> Congestion-rate: For any granularity of traffic (packet, flow, > >>> aggregate, link, etc.), the instantaneous rate of traffic > >>> discarded or marked due to congestion. Conceptually, the > >>> instantaneous bit-rate of the traffic weighted by the > >>> instantaneous congestion it experiences. Usually expressed in > >>> b/s. > >> > >> This is confusing, and the term isn't used in the document. I > suggest > >> removing the definition. (Otherwise, we need to see how it will be > used > >> and make sure we understand that concept before wordsmithing.) > > > > For similar reasons, I considered removing this (during the threads > > with Georgios & Mikael). But I figured these are definitions for > > later ConEx use, not just in this doc. When talking about policers, > > we will need this definition. > > Future documents can always refer to future definitions... > > > How about explicitly saying... > > > > Congestion-rate: This concept is not needed in the current > > document but, as it follows naturally from congestion-volume, it is > > defined here for use in other ConEx documents. For any granularity of > > traffic (packet, flow, ... > > Unnecessarily confusing to the casual reader. > > >>> Consumer: A general term representing the contractual entity such > as > >>> a user or business or institution that uses the service of a > >>> network provider. There is no implication that the contract > has > >>> to be commercial; for instance the consumers of a University or > >>> enterprise network service would be students or employees and > they > >>> might well be required to comply with some form of contract or > >>> acceptable use policy. There is also no implication that the > >>> consumer is necessarily an end-consumer. Where two networks > form > >>> a customer-provider relationship, the term consumer is also > >>> intended to cover the customer network. > >> > >> Personally, I would prefer "customer" to "consumer". "Consumer" > >> suggests we're talking about the receiver as opposed to the sender. > > > > Ug. Customer is too loaded with commercial connotations. ConEx is > > equally applicable to non-ISP scenarios and we mustn't rule that out > > with our language. > > I think you're way over-sensitive here. "Customer" contains no > implications of what the contractual relationship is -- or even if > a contract is recognized to exist. And "consumer" does bring confusion > about sender vs. receiver. > > > I can't think of another word (neither can the Thesaurus) other than > > punter :) > > > > Do you really think Consumer will get confused with receiver? > > We could add: > > > > "Note: The Consumer could be a sender and/or receiver; it is used in > > the sense of a consumer of service (not to be confused with a > > consumer of data)." > > That would help -- if you're unwilling to go back to "customer". > > >>> [ConEx-Abstract-Mech] gives further definitions for aspects of > ConEx > >>> to do with protocol mechanisms. > >> > >> I'm not sure quite what this means: does it imply that we need to > >> read abstract-mech for definitions used in this document? (I would > >> prefer we not ask our readers to do that.) > > > > How about: > > Because ConEx protocol mechanisms are outside this document's > > scope, mechanism-related definitions can be found in > > [ConEx-Abstract-Mech]. > > Much clearer! > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From acooper@cdt.org Mon Jul 18 21:53: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 134F421F86D7 for ; Mon, 18 Jul 2011 21:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z0Gf0+KtHOb for ; Mon, 18 Jul 2011 21:53:07 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7041D21F86C0 for ; Mon, 18 Jul 2011 21:53:07 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 19 Jul 2011 00:53:02 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <201107181838.p6IIcLbV027438@bagheera.jungle.bt.co.uk> Date: Tue, 19 Jul 2011 05:53:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73F0F934-B777-465D-8A23-58826F21292E@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> <201107181838.p6IIcLbV027438@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 19 Jul 2011 04:53:08 -0000 Hi Bob, Inline... On Jul 18, 2011, at 7:38 PM, Bob Briscoe wrote: > Alissa, >=20 > I'll deal with this in small parts. >=20 > At 18:58 18/07/2011, Alissa Cooper wrote: >> 2. Concepts and 3. Definitions -- Right now the only concepts that = are fully teed up in the Concepts section are congestion volume and = blame (which I hope will become accountability or something similar as = others have suggested). So I think it's safe to separate the concepts = section from the definitions section. >=20 > Concepts introduces all of: > - congestion > - congestion-volume > - upstream/downstream congestion > all under the framework of cutting accountability different ways. >=20 > The definitions section is then a formalisation of the prose that = precedes it. > The addition of provider/consumer is related to the upstream/downstram = split, but the link isn't explicitly made (no need IMO). Fair enough. >=20 > Then, what are you implying about the non-goals/misconceptions = subsection, which you've not mentioned? Nothing. I find it confusing to start the document by saying what it = doesn't do, that's all. Alissa >=20 > I'm about to go offline, so will continue in the morning... >=20 >=20 > Bob >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 From acooper@cdt.org Mon Jul 18 22:10: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 B065921F86A2 for ; Mon, 18 Jul 2011 22:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKsNIyB6-QC3 for ; Mon, 18 Jul 2011 22:10:08 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id E257C21F86A1 for ; Mon, 18 Jul 2011 22:10:07 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 19 Jul 2011 01:09:28 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> Date: Tue, 19 Jul 2011 06:09:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 05:10:08 -0000 Hi Bob, I have a few questions/suggestions on the definitions. On Jul 11, 2011, at 6:14 PM, Bob Briscoe wrote: > 2.1. Definitions >=20 > Congestion: Congestion occurs when any user's traffic suffers > increased delay, loss or ECN marking as a result of one or more > network resources becoming overloaded. =20 i) Does "increased" apply only to delay, or also to loss and markings? I = would expect it to be the former, but from this construction it's not = clear. Might help to say "loss, ECN marking, or increased delay." ii) What is the "increase" from? Increase from zero? Increase from some = baseline? If "increased" only applies to delay this probably doesn't = need clarification, but if it applies to loss and marking too, it = probably does. > For the purposes of ConEx, > the focus is on concrete signals of congestion (ECN and loss), > therefore delay is set to one side. Congestion is measured as = the > probability of loss or the probability of ECN marking, usually > expressed as dimensionless percentages. >=20 > Consumer: A general term representing the contractual entity such = as > a user or business or institution that uses the service of a > network provider. There is no implication that the contract has > to be commercial; for instance the consumers of a University or > enterprise network service would be students or employees and = they > might well be required to comply with some form of contract or > acceptable use policy. There is also no implication that the > consumer is necessarily an end-consumer. Where two networks form > a customer-provider relationship, the term consumer is also > intended to cover the customer network. If people have problems with "Consumer" you could substitute "User" and = I think that would work fine. >=20 > Network provider: (also 'operator'): the term is not confined to > Internet service providers (ISPs) who run commercial public > networks but is also intended to generalise to operators of > enterprise, campus and other networks. I find it confusing to define this in the negative. A suggestion: Network provider (or "operator"): Operator of a commercial, enterprise, = campus, or other network. Alissa From swmike@swm.pp.se Mon Jul 18 23:14:45 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 6986821F86A2 for ; Mon, 18 Jul 2011 23:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 bVFTpDBjr1d1 for ; Mon, 18 Jul 2011 23:14:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8529821F84FC for ; Mon, 18 Jul 2011 23:14:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 884739C; Tue, 19 Jul 2011 08:14:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 852D49A; Tue, 19 Jul 2011 08:14:39 +0200 (CEST) Date: Tue, 19 Jul 2011 08:14:39 +0200 (CEST) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <002e01cc458a$8a39f800$9eade800$@com> Message-ID: References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> <002e01cc458a$8a39f800$9eade800$@com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 06:14:45 -0000 On Mon, 18 Jul 2011, Toby Moncaster wrote: > Perhaps what we have to get across is that we are coming up with a way > to apportion responsibility between operators and users. Make more use > of the Tragedy of the Commons argument, using a suitable analogy to show > why such a world is unsustainable without either heavy handed > intervention by ISPs or huge investment (at a time when investment is > not high on the agenda) or by using ConEx. I'd just like to point out that the ingress policer needed to actually make conex police traffic, isn't going to be for free. It seems to be a quite advanced device. So what I'd like to see is ConEx do two things: Show congestion to everybody, the user and ISP alike. I would like to see it also differentiate between self-congestion (access link) and shared-link congestion (everything else than the access link), but I have no idea how to do this. It would also be good to show which direction the congestion is in. Should we give guidance to how the IP stack should expose this information to the user? In the end, I want an end-user to be able to differentiate between an ISP which doesn't congest its core/distribution, and one that does, by means of showing percent of traffic that is exposed to congestion (or some other metric). I'd also like us to give guidance to AQM for different media, like wifi (which is half duplex), ADSL and other typical medias (also in the core, WRED drop settings for instance). This is all in the context of bufferbloat (I hate that term, but it seems to have gained traction), and how it should be handled to give the best compromise between speed for TCP and low-latency for interactive applications. -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Tue Jul 19 05:05: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 A970F21F86D8 for ; Tue, 19 Jul 2011 05:05:23 -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=[AWL=0.000, 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 665BPs7-Udfw for ; Tue, 19 Jul 2011 05:05:23 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BA9EB21F8661 for ; Tue, 19 Jul 2011 05:05:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 349F133C27; Tue, 19 Jul 2011 08:05:22 -0400 (EDT) Date: Tue, 19 Jul 2011 08:05:22 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110719120522.GE53567@verdi> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> <002e01cc458a$8a39f800$9eade800$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 12:05:23 -0000 Mikael Abrahamsson wrote: > On Mon, 18 Jul 2011, Toby Moncaster wrote: > >> Perhaps what we have to get across is that we are coming up with a way >> to apportion responsibility between operators and users. Make more use >> of the Tragedy of the Commons argument, using a suitable analogy to show >> why such a world is unsustainable without either heavy handed >> intervention by ISPs or huge investment (at a time when investment is >> not high on the agenda) or by using ConEx. > > I'd just like to point out that the ingress policer needed to actually > make conex police traffic, isn't going to be for free. It seems to be a > quite advanced device. An ingress policer _could_ be rather complicated, but IMHO this really isn't necessary. We seem to be letting ourselves think in terms of each policer being flow-aware -- in order to police the "right" target. But if an ingress policer is close enough to the source it needn't be flow-aware -- the user is in the best position to balance demands of different flows, and the policer merely needs to enforce an overall limit. If, OTOH, various users are aggregated before the ingress policer, the ingress policer is in a very poor position to sort them out -- especially with forging of source addresses being so easy. I think we're wasting our time to try. > So what I'd like to see is ConEx do two things: > > Show congestion to everybody, the user and ISP alike. Do you mean something beyond simply having in the IP packet in a well-known place? If so, what? > I would like to see it also differentiate between self-congestion > (access link) and shared-link congestion (everything else than the > access link), but I have no idea how to do this. Neither do I... nor do I see any benefit. At any point, it's trivial to distinguish upstream from downstream. Now, if you mean that self-congestion shouldn't be reported all the way along the path, that's a user's choice which could be implemented by moving the "sender" function past the ingress bottleneck. But I don't think many users could be bothered. > It would also be good to show which direction the congestion is in. Oh, but we do. Any congestion on the return-path from receiver to sender is Somebody-Else's-Problem. > Should we give guidance to how the IP stack should expose this > information to the user? I don't understand the question. > In the end, I want an end-user to be able to differentiate between > an ISP which doesn't congest its core/distribution, and one that does, > by means of showing percent of traffic that is exposed to congestion > (or some other metric). Recall that ISPs have two quite separable functions: to accept IP packets to forward them "somewhere closer", and to advertise themselves as able to deliver packets to particular IP ranges. There's no necessary correlation between congestion on these two functions. In principle, an ISP could entirely avoid congestion of the first: in practice, most come "close enough". But for the second, it's quite impossible to avoid congestion _under_some_conditions_ where the receiving customer is "offered" traffic (often from diverse sources) greater than his link can handle. The receiver already has the information on incoming congestion without ConEx. The sender _would_ have an additional signal from ConEx; but it's unlikely it will tell him much about outgoing congestion _within_ his ISP's control. (There is, of course a special-case, where the sender's modem contends for upstream bandwidth in cable networks, and I guess that technically is "within" the ISP's control -- but that's more a matter of diagnosis of the issue than questionable provisioning...) > I'd also like us to give guidance to AQM for different media, like wifi > (which is half duplex), Indeed! an interesting problem area. I'm not sure what would help... > ADSL and other typical medias (also in the core, WRED drop settings > for instance). Do you have suggestions on what would help? > This is all in the context of bufferbloat (I hate that term, but it > seems to have gained traction), and how it should be handled to give > the best compromise between speed for TCP and low-latency for > interactive applications. Ah, yes. Buffer tuning is fairly well understood by ISPs, but the distribution-of-information channels don't work well. :^( If you think ConEx could help, please say how! -- John Leslie From swmike@swm.pp.se Tue Jul 19 05:34: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 11FE121F8906 for ; Tue, 19 Jul 2011 05:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, J_BACKHAIR_33=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 TLGthG32XryK for ; Tue, 19 Jul 2011 05:34:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E86BE21F88B7 for ; Tue, 19 Jul 2011 05:34:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D0BB09C; Tue, 19 Jul 2011 14:34:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CF7149A; Tue, 19 Jul 2011 14:34:09 +0200 (CEST) Date: Tue, 19 Jul 2011 14:34:09 +0200 (CEST) From: Mikael Abrahamsson To: John Leslie In-Reply-To: <20110719120522.GE53567@verdi> Message-ID: References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> <002e01cc458a$8a39f800$9eade800$@com> <20110719120522.GE53567@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 12:34:12 -0000 On Tue, 19 Jul 2011, John Leslie wrote: > But if an ingress policer is close enough to the source it needn't be > flow-aware -- the user is in the best position to balance demands of > different flows, and the policer merely needs to enforce an overall > limit. I don't see the need for anything more than we have today then? What would a conex enabled policer give if it's one policer per access port anyway? And how would it work when it's connected to an ISP<->ISP peering port? > If, OTOH, various users are aggregated before the ingress policer, > the ingress policer is in a very poor position to sort them out -- > especially with forging of source addresses being so easy. I think we're > wasting our time to try. I always thought the policer acted on aggregation ports, ie for several users. >> Show congestion to everybody, the user and ISP alike. > > Do you mean something beyond simply having in the IP packet in a > well-known place? If so, what? I'm talking the congestion signals (re-ECN etc) that seems to be the centarl goal of ConEx. >> I would like to see it also differentiate between self-congestion >> (access link) and shared-link congestion (everything else than the >> access link), but I have no idea how to do this. > > Neither do I... nor do I see any benefit. At any point, it's trivial > to distinguish upstream from downstream. There is tremendous benefit from differentiating "my access link is congesting because *I* am using it" to "my ISP doesn't have enough capacity so because of *others* I can't use my full access speed", for the user point of view. > Oh, but we do. Any congestion on the return-path from receiver to > sender is Somebody-Else's-Problem. I don't agree at all. If someone is dropping the traffic I'm about to receive, I want to know about it. >> Should we give guidance to how the IP stack should expose this >> information to the user? > > I don't understand the question. I want to empower the user with knowledge about congestion. I thought this was a central goal of ConEx, to *expose* congestion. > In principle, an ISP could entirely avoid congestion of the first: in > practice, most come "close enough". But for the second, it's quite > impossible to avoid congestion _under_some_conditions_ where the > receiving customer is "offered" traffic (often from diverse sources) > greater than his link can handle. An ISP can certainly try, and I don't agree that this is "impossible". Of course the congestion will be destination/flow-dependent, but this is something that has to be taken into account. > The receiver already has the information on incoming congestion > without ConEx. The sender _would_ have an additional signal from > ConEx; but it's unlikely it will tell him much about outgoing > congestion _within_ his ISP's control. Well, even if the information is already available, it's not exposed to the user. > Do you have suggestions on what would help? So, for core links, my suggestion is to use WRED and drop/set ECN at a certain queue depth, for instance 20-30 ms queue depth. For access links, I'd like to see "fair queuing" (RFC970) enabled on a lot more ADSL/cable modems/Wifi routers, and also in hosts. RFC1254 also lists different ways of handling this. Generally, I'd say not much of this is actually in use on the Internet today, 25+ years later :P I run fair-queue on my access link at home, it works great. > Ah, yes. Buffer tuning is fairly well understood by ISPs, but the > distribution-of-information channels don't work well. :^( If you think > ConEx could help, please say how! Er, considering basically NONE of the typical CPEs in use today does anything other than FIFO with a lot of buffers, I'd say if the ISP understands bufferbloat, they haven't communicated this to the purchasing department who controls CPE purchases, because if they did, the typical ADSL router would do better things than FIFO for upstream buffer management. So I would like to have ConEx describe how buffering should be implemented in all devices who might experience congestion on the outgoing interface (hosts and routers, most likely different advice, ConEx perhaps should define different classes of devices that should do different things), this should be very good guidance going forward. Let me describe a typical home access scenario to visualise what I'm trying to say: The host IP stack is sending 5 different TCP flows. The IP stack is dumping these packets into an egress Wifi NIC FIFO buffer, which is emptied by the Wifi hardware as packets are being passed out the wifi air interface. When there is a 20ms stop in the wifi communication, this affects all flows, and the FIFO buffer might be quite big. When it arrives in the wifi router, it's now going to split up the traffic because one flow was going to the ethernet attached file server, and 4 was going out the ADSL interface. The ethernet is faster than the wifi, so the stupid FIFO buffering here doesn't matter, but the ADSL interface is an ATM FIFO single PVC again, with quite large buffer, so this can easily reach hundreds of milliseconds of buffering when this is full. Even if the IP stack might do AQM, the cell buffer is so big that the AQM empties into a 10-20ms cell FIFO anyway, so the AQM is crippled even if it exists. Now we enter the DSLAM and it might have a 100 meg ethernet upstream interface, and you now have many hundreds of customers on this 100 meg interface which means it's full, but it's a L2 switch interface and it only has 5 ms of FIFO buffers with tail drop so it'll just drop 100% of packets at a certain queue depth. After this we hit a 1G router interface with 600ms FIFO, where if it's full, you'll get a lot of delay, often without any drops because most TCP flows will never reach full queue depth before the bandwidth/delay product is larger than available TCP window. Phew, that was a lot of text. Anyhow, it was just an example of all the different places where packets can be dropped/queued in the network and how they might work today, and I believe there are a LOT to be done to improve how all these different queue points can handle traffic to give the end user a better network experience. This is both within the home and within the ISP network. -- Mikael Abrahamsson email: swmike@swm.pp.se From bob.briscoe@bt.com Tue Jul 19 09:20: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 2D56E21F84F7 for ; Tue, 19 Jul 2011 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 WoTtqAvrGnmK for ; Tue, 19 Jul 2011 09:20:37 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 61EAF21F84F1 for ; Tue, 19 Jul 2011 09:20:36 -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); Tue, 19 Jul 2011 17:20:35 +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, 19 Jul 2011 17:20:35 +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 1311092434220; Tue, 19 Jul 2011 17:20:34 +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 p6JGKWun031942; Tue, 19 Jul 2011 17:20:32 +0100 Message-Id: <201107191620.p6JGKWun031942@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jul 2011 17:20:34 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@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: 19 Jul 2011 16:20:35.0496 (UTC) FILETIME=[CA193A80:01CC462F] Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 16:20:38 -0000 Alissa, At 06:09 19/07/2011, Alissa Cooper wrote: >Hi Bob, > >I have a few questions/suggestions on the definitions. > >On Jul 11, 2011, at 6:14 PM, Bob Briscoe wrote: > > 2.1. Definitions > > > > Congestion: Congestion occurs when any user's traffic suffers > > increased delay, loss or ECN marking as a result of one or more > > network resources becoming overloaded. > >i) Does "increased" apply only to delay, or also to loss and >markings? I would expect it to be the former, but from this >construction it's not clear. Might help to say "loss, ECN marking, >or increased delay." Yes, I think the latter was meant. Thanks However, we're likely to take John's suggestion and just cut down the definition of congestion to how it is measured (loss & ECN), removing this sentence entirely. >ii) What is the "increase" from? Increase from zero? Increase from >some baseline? If "increased" only applies to delay this probably >doesn't need clarification, but if it applies to loss and marking >too, it probably does. Another reason to cut out this sentence! > > For the purposes of ConEx, > > the focus is on concrete signals of congestion (ECN and loss), > > therefore delay is set to one side. Congestion is measured as the > > probability of loss or the probability of ECN marking, usually > > expressed as dimensionless percentages. > > > > > > > Consumer: A general term representing the contractual entity such as > > a user or business or institution that uses the service of a > > network provider. There is no implication that the contract has > > to be commercial; for instance the consumers of a University or > > enterprise network service would be students or employees and they > > might well be required to comply with some form of contract or > > acceptable use policy. There is also no implication that the > > consumer is necessarily an end-consumer. Where two networks form > > a customer-provider relationship, the term consumer is also > > intended to cover the customer network. > >If people have problems with "Consumer" you could substitute "User" >and I think that would work fine. I'm afraid user always means one human, so it precludes a business, a University or a home. We need a term for a network of users, whether small or large, that gets connectivity to the Internet from another network. > > > > Network provider: (also 'operator'): the term is not confined to > > Internet service providers (ISPs) who run commercial public > > networks but is also intended to generalise to operators of > > enterprise, campus and other networks. > >I find it confusing to define this in the negative. A suggestion: > >Network provider (or "operator"): Operator of a commercial, >enterprise, campus, or other network. Good. Thanks for the suggestions Bob >Alissa ________________________________________________________________ Bob Briscoe, BT Innovate & Design From acooper@cdt.org Tue Jul 19 09:27: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 2A72121F867F for ; Tue, 19 Jul 2011 09:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8QXvXc4BHRA for ; Tue, 19 Jul 2011 09:27:25 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 89AF821F85B2 for ; Tue, 19 Jul 2011 09:27:25 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 19 Jul 2011 12:27:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <201107191620.p6JGKWun031942@bagheera.jungle.bt.co.uk> Date: Tue, 19 Jul 2011 17:27:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42B0A53C-1446-48DC-B10B-A7E77780F48B@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <201107191620.p6JGKWun031942@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 16:27:26 -0000 Hi Bob, On Jul 19, 2011, at 5:20 PM, Bob Briscoe wrote: >>=20 >> > Consumer: A general term representing the contractual entity = such as >> > a user or business or institution that uses the service of a >> > network provider. There is no implication that the contract = has >> > to be commercial; for instance the consumers of a University = or >> > enterprise network service would be students or employees and = they >> > might well be required to comply with some form of contract or >> > acceptable use policy. There is also no implication that the >> > consumer is necessarily an end-consumer. Where two networks = form >> > a customer-provider relationship, the term consumer is also >> > intended to cover the customer network. >>=20 >> If people have problems with "Consumer" you could substitute "User" = and I think that would work fine. >=20 > I'm afraid user always means one human, so it precludes a business, a = University or a home. We need a term for a network of users, whether = small or large, that gets connectivity to the Internet from another = network. The exact same logic applies to "consumer." Since you have to go to the = length of explaining it as you do above for consumer, you could do it = just as well for "user." I don't care either way, but I think either = could work. Best, Alissa= From bob.briscoe@bt.com Tue Jul 19 09:29: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 2A65A1F0C3D for ; Tue, 19 Jul 2011 09:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 pfdf5xXhTC4f for ; Tue, 19 Jul 2011 09:29:32 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C91F0C3B for ; Tue, 19 Jul 2011 09:29:32 -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, 19 Jul 2011 17:29:31 +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, 19 Jul 2011 17:29:31 +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 131109296984; Tue, 19 Jul 2011 17:29:29 +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 p6JGTQge031996; Tue, 19 Jul 2011 17:29:27 +0100 Message-Id: <201107191629.p6JGTQge031996@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jul 2011 17:29:29 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <73F0F934-B777-465D-8A23-58826F21292E@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> <201107181838.p6IIcLbV027438@bagheera.jungle.bt.co.uk> <73F0F934-B777-465D-8A23-58826F21292E@cdt.org> 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: 19 Jul 2011 16:29:31.0052 (UTC) FILETIME=[095096C0:01CC4631] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 19 Jul 2011 16:29:33 -0000 Alissa, At 05:53 19/07/2011, Alissa Cooper wrote: >Hi Bob, > >Inline... > >On Jul 18, 2011, at 7:38 PM, Bob Briscoe wrote: > > > Alissa, > > > > I'll deal with this in small parts. > > > > At 18:58 18/07/2011, Alissa Cooper wrote: > >> 2. Concepts and 3. Definitions -- Right now the only concepts > that are fully teed up in the Concepts section are congestion > volume and blame (which I hope will become accountability or > something similar as others have suggested). So I think it's safe > to separate the concepts section from the definitions section. > > > > Concepts introduces all of: > > - congestion > > - congestion-volume > > - upstream/downstream congestion > > all under the framework of cutting accountability different ways. > > > > The definitions section is then a formalisation of the prose that > precedes it. > > The addition of provider/consumer is related to the > upstream/downstram split, but the link isn't explicitly made (no need IMO). > >Fair enough. But I've taken the message that this link obviously needs to be made clearer. > > > > Then, what are you implying about the non-goals/misconceptions > subsection, which you've not mentioned? > >Nothing. I find it confusing to start the document by saying what it >doesn't do, that's all. We're 6 pages into the text by now (not incl. the 2 pages of preamble). Do you really mean "confusing", or just unnecessary? Given how many people on this list have assumed some non-goals are goals, a number of people have been saying (including me) that we need to explicitly unhitch new readers from some of the more common preconceptions they seem to have. I agree this shouldn't be done before we've said what ConEx is, but that's why it's positioned here, after the Intro, Concepts and Definitions, at the point where the reader should now 'get it', before reading on for the detail. Still disagree? Bob >Alissa > > > > > I'm about to go offline, so will continue in the morning... > > > > > > Bob > > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Jul 19 09:48: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 4AD6A21F84DA for ; Tue, 19 Jul 2011 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 draF2GP5AA83 for ; Tue, 19 Jul 2011 09:48:27 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2A04421F84DE for ; Tue, 19 Jul 2011 09:48:26 -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); Tue, 19 Jul 2011 17:48:26 +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, 19 Jul 2011 17:48:25 +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 1311094103699; Tue, 19 Jul 2011 17:48:23 +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 p6JGmNIo032117; Tue, 19 Jul 2011 17:48:23 +0100 Message-Id: <201107191648.p6JGmNIo032117@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jul 2011 17:48:23 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <42B0A53C-1446-48DC-B10B-A7E77780F48B@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <201107191620.p6JGKWun031942@bagheera.jungle.bt.co.uk> <42B0A53C-1446-48DC-B10B-A7E77780F48B@cdt.org> 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: 19 Jul 2011 16:48:25.0791 (UTC) FILETIME=[ADAC04F0:01CC4633] Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 19 Jul 2011 16:48:31 -0000 Alissa, The difference is that the proposed defintion of=20 the word consumer actually matches one of its=20 dictionary meanings. Whereas the definition of=20 "user" would have to contradict the natural=20 meaning of the word user, which is definitely not good practice. con=B7sum=B7er [kuhn-soo-mer] =96noun 1. a person or thing that consumes. 2. Economics . a person or organization that uses a commodity or service. courtesy dictionary.com Bob At 17:27 19/07/2011, Alissa Cooper wrote: >Hi Bob, > >On Jul 19, 2011, at 5:20 PM, Bob Briscoe wrote: > >> > >> > Consumer: A general term representing the contractual entity such= as > >> > a user or business or institution that uses the service of a > >> > network provider. There is no implication that the contract has > >> > to be commercial; for instance the consumers of a University or > >> > enterprise network service would be students or employees and= they > >> > might well be required to comply with some form of contract or > >> > acceptable use policy. There is also no implication that the > >> > consumer is necessarily an end-consumer. Where two networks= form > >> > a customer-provider relationship, the term consumer is also > >> > intended to cover the customer network. > >> > >> If people have problems with "Consumer" you=20 > could substitute "User" and I think that would work fine. > > > > I'm afraid user always means one human, so it=20 > precludes a business, a University or a home.=20 > We need a term for a network of users, whether=20 > small or large, that gets connectivity to the Internet from another= network. > >The exact same logic applies to "consumer."=20 >Since you have to go to the length of explaining=20 >it as you do above for consumer, you could do it=20 >just as well for "user." I don't care either=20 >way, but I think either could work. > >Best, >Alissa ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From nanditad@google.com Tue Jul 19 20:25:07 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 C4F7311E808B for ; Tue, 19 Jul 2011 20:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2tWt1ouD8qK for ; Tue, 19 Jul 2011 20:25:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B4FFD228012 for ; Tue, 19 Jul 2011 20:25:06 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p6K3P5GG001362 for ; Tue, 19 Jul 2011 20:25:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311132305; bh=uwMpDJE47LpvGj1LadJ9V4ame/c=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=SU56hTlix8nGXdZ2fNAtQ+joUbHPp1xYY4gjlQMosO9REF57SrZazBvKKwdeql5Kl zTrNn8khZ9DHUcKuCqKzQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=ioBAuQwax3+QqJmxiUTJ5E3VOQLDeSPlretscohIngE/Yu+Bk0K+IdqtbErJTR2jK vMowYaBrDOdrKwmlEbFiA== Received: from yih10 (yih10.prod.google.com [10.243.66.202]) by wpaz29.hot.corp.google.com with ESMTP id p6K3P4Lx017150 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Jul 2011 20:25:05 -0700 Received: by yih10 with SMTP id 10so2326009yih.15 for ; Tue, 19 Jul 2011 20:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=TsXAXYRsjtpKRLqxtaaWQzxNJcdA92OllyCwyD3kIA0=; b=LBoqe0Qir2Dl7QFlyP8clqsj9hMwtnpOkHnq85VGLqFs9ajIucjpo1n342xDmWp7KJ CqRWFjGS/n5IUdJdmORw== MIME-Version: 1.0 Received: by 10.150.47.42 with SMTP id u42mr7255971ybu.127.1311132304660; Tue, 19 Jul 2011 20:25:04 -0700 (PDT) Received: by 10.150.98.14 with HTTP; Tue, 19 Jul 2011 20:25:04 -0700 (PDT) Date: Tue, 19 Jul 2011 20:25:04 -0700 Message-ID: From: Nandita Dukkipati To: Bob Briscoe , "Woundy, Richard" Content-Type: multipart/alternative; boundary=000e0cd70ddc45d86704a877c720 X-System-Of-Record: true Cc: conex@ietf.org Subject: [conex] Comments on 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: Wed, 20 Jul 2011 03:25:07 -0000 --000e0cd70ddc45d86704a877c720 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi. Following are my comments on conex-concepts-uses draft -- as an individual contributor. First of, the draft shows a marked improvement over the previous version an= d has made forward progress. Good work on this front! But there is still plenty of room for improvement so here it goes - The high order bits: 1. I like the fact that the draft focusses on one killer Conex application which is traffic management; the remaining ones are nice-to-have use cases. The structure that Alissa Cooper proposed looks promising in bringing this feature out more explicitly. 2. The draft starts out reading fresh, focussed and promising but the quality deteriorates significantly as we go further on into Sections 5, 6, 7. 3. The language used throughout seems a bit too casual for an Internet Draft. There's significant amount of work to be done in terms of tidying up the writing. 4. There was one thing that I was really looking forward to and didn't find= . There are two main ideas necessary to get across the Conex idea - a) congestion volume matters, and b) knowing about "rest-of-path" congestion o= r downstream congestion matters. The draft brings out point (a) clearly, but surprisingly there is very little on (b). I find that most folks new to Conex get point (a) quickly and then are stuck thinking about why one would ever need downstream congestion. ------------ Nits in individual sections: 1. Figure 1: Can be made simpler to parse without sacrificing information. Has too many arrows currently. 2. Sec. 2 =93The blame for congestion...=94 Accountability for congestion sounds better than blame. I know there's extensive discussion on this in a separate thread... 3. Sec. 2 The introduction part of Sec. 2 (preceding the definitions in Sec. 2.1) is wordy/rambling and I don=92t see what its primary purpose is. It also ends rather abruptly. However, the good parts are the examples; they add a _lot_ of clarity. The definitions in Sec 2.1 by themselves do a great job of introducing key Conex concepts. My suggestion would be to jump in straight to the definitions and move some of the intro. text of Sec. 2 (and examples) to after the definitions - then it serves to nicely connect the different concepts. 4. Sec 3.1 "All of these current approaches suffer from some general limitations. First, they introduce performance uncertainty...." "Second, none of the approaches is able to make use of...." Switch order of the first and second reasons, as the second one is by far the most important shortcoming of existing traffic management schemes. 5. Sec. 5.1 =93the only reason their networks work as a commercial concern is that...= =94 You mean commercial success? 6. Sec 5.3. Consequence: User-Controlled Intra-Class Quality of Service (QoS) This section is wordy and rambling - need a simpler way of directly getting to the point. QoS part was quite bad in previous drafts and it continues to be here. 7. Another Consequence: Preventing Congestion Collapse. I see the point that you are getting at, but this a very strong claim with extremely little detail to back it up. 8. Sec. 6. Deployment Arrangements The list of bullet points is not that helpful. Needs some thought on how on= e can articulate the deployment part without relying too much on the mechanisms draft. 9. Sec. 7 The Section should be named 'Potential Issues' - keeps the section focussed on real issues as opposed to those which are non-issues. --000e0cd70ddc45d86704a877c720 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi. Following are my comments=A0<= /font>on conex-concepts-uses draft -- as an individual contributor= .

First of, th= e draft shows a marked improvement over the previous version and has made f= orward progress. Good work on this front! But there is still plenty of room for improvement so here it goes= -

The high order bits:

1. I like the fact t= hat the draft focusses on one killer Conex application which is traffic man= agement; the remaining ones are nice-to-have use cases. The structure that = Alissa Cooper proposed looks promising in bringing this feature out more ex= plicitly.

2. The draft starts out reading fresh, focusse= d and promising but the quality deteriorates significantly as we go further= on into Sections 5, 6, 7.

3. The language used throughout seems a bit to= o casual for an Internet Draft. There's significant amount of work to b= e done in terms of tidying up the writing.=A0

4. There was one thing that I was really looki= ng forward to and didn't find. There are two main ideas necessary to ge= t across the Conex idea - a) congestion volume matters, and b) knowing abou= t "rest-of-path" congestion or downstream congestion matters. The= draft brings out point (a) clearly, but surprisingly there is very little = on (b). I find that most folks new to Conex get point (a) quickly and then = are stuck thinking about why one would ever need downstream congestion.=A0<= /div>
------------

Nits in individual sections:

1. Figure 1: Can be made simpler to parse without sacri= ficing information. Has too many arrows currently.

2. Sec. 2
=93The blame for congestion...=94
Accountability for congestion sounds better than blame. I k= now there's extensive discussion on this in a separate thread...=

3. Sec. 2
The introduction part of Sec. 2 (preceding the definitions = in Sec. 2.1) is wordy/rambling and I don=92t see what its primary purpose i= s. It also ends rather abruptly. However, the good parts are the examples; = they add a _lot_ of clarity.=A0

The definitions in Sec 2.1 by themselves do a great job of introducing key= Conex concepts. My suggestion would be to jump in straight to the definiti= ons and move some of the intro. text of Sec. 2 (and examples) to after the = definitions - then it serves to nicely connect the different concepts.

4. Sec 3.1
"All of these current approaches suffer from some gene= ral limitations. First, they introduce performance uncertainty...."
"Second, none of the approaches is able to make use of= ...."

Switch order of the first and second reasons, as the second= one is by far the most important shortcoming of existing traffic managemen= t schemes.

5. Sec. 5.1
=93the only reason their networks work as a commercial conc= ern is that...=94
You mean commercial success?
=
6. Sec 5.3. =A0C= onsequence: User-Controlled Intra-Class Quality of Service (QoS)
This section is wordy and rambling - need a simpler way of = directly getting to the point. QoS part was quite bad in previous drafts an= d it continues to be here.

7. Another Consequence: Preventing Congestion Collapse.
I see the point that you are getting at, but this a very st= rong claim with extremely little detail to back it up.

8. Sec. 6. Deployment Arrangements
The list of bullet points is n= ot that helpful. Needs some thought on how one can articulate the deploymen= t part without relying too much on the mechanisms draft.

9. Sec. 7
The Section = should be named 'Potential Issues' - keeps the section focussed on = real issues as opposed to those which are non-issues.
--000e0cd70ddc45d86704a877c720-- From bob.briscoe@bt.com Wed Jul 20 10:07: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 EDD4B21F859F for ; Wed, 20 Jul 2011 10:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 MFWtnMiObDjJ for ; Wed, 20 Jul 2011 10:07:28 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1D21F8599 for ; Wed, 20 Jul 2011 10:07:24 -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); Wed, 20 Jul 2011 18:07: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); Wed, 20 Jul 2011 18:07: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 1311181642266; Wed, 20 Jul 2011 18:07: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 p6KH7LPR004722; Wed, 20 Jul 2011 18:07:21 +0100 Message-Id: <201107201707.p6KH7LPR004722@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jul 2011 18:07:24 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> References: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> 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: 20 Jul 2011 17:07:23.0175 (UTC) FILETIME=[7E04CB70:01CC46FF] Cc: conex@ietf.org Subject: Re: [conex] "traffic management" 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: Wed, 20 Jul 2011 17:07:31 -0000 Alissa, Isn't traffic management surely a very general term that means "managing traffic" (self-evidently). It doesn't have to imply who is managing traffic. The word 'traffic' gives it an implication of managing the bulk of traffic, not individual flows. So it would generally be associated with an operator managing traffic. But it could also mean the overall outcome of an end-system doing congestion control on all its flows. IOW, it's a useful general term for a range of functions that alter the overall profile of traffic. We certainly have to use the term traffic management when talking about all the things operators do today (partly because they aren't directly managing congestion, and in some cases they aren't even trying to indirectly manage congestion). We can say that ConEx allows operators to focus their traffic management on managing congestion. But I don't think we should then call it congestion management, because that would risk being confused with end-system congestion control. Do you think a definition entry for this would help? Or if it said traffic management is managing traffic, would it just add empty bytes to the draft? [BTW, in public policy circles, they use the phrase network management to mean operator's traffic management. I tell them this is liable to misinterpretation in the industry.] Bob At 18:11 18/07/2011, Alissa Cooper wrote: >I've been reviewing draft-ietf-conex-concepts-uses-02 and may send a >few emails about different things. > >I'm wondering what is meant by "traffic management" as the term is >used in the draft. Sometimes it seems to encompass only actions that >operators might take; other times it seems to also include >endpoint-controlled management of congestion (e.g., in section 3). >Sometimes it seems to be used in a way that is synonymous with >"congestion management"; other times it seems to take on the more >expansive connotation (that I often find used in the UK), >encompassing motivations beyond mitigating congestion (e.g., >deferring capacity investment by reducing peak-hour usage). > >If what we're really talking about is the management of congestion >by network operators, it might be better to call it "congestion >management" and only use the term when referring to network-based >management. If some more expansive concept is intended, that >probably needs to be clarified. > >Alissa >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Jul 20 10:29: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 F21D621F89BA for ; Wed, 20 Jul 2011 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytegrUFSa4I6 for ; Wed, 20 Jul 2011 10:29:04 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C421F85F6 for ; Wed, 20 Jul 2011 10:29:04 -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); Wed, 20 Jul 2011 18:29:03 +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); Wed, 20 Jul 2011 18:29:02 +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 1311182941668; Wed, 20 Jul 2011 18:29:01 +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 p6KHSxiY004854; Wed, 20 Jul 2011 18:28:59 +0100 Message-Id: <201107201728.p6KHSxiY004854@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jul 2011 18:29:02 +0100 To: Nandita Dukkipati From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_162620385==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Jul 2011 17:29:02.0918 (UTC) FILETIME=[84B9D660:01CC4702] Cc: conex@ietf.org Subject: Re: [conex] Comments on 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: Wed, 20 Jul 2011 17:29:06 -0000 --=====================_162620385==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Nandita, At 04:25 20/07/2011, Nandita Dukkipati wrote: >Hi. Following are my comments on conex-concepts-uses draft -- as an >individual contributor. > >First of, the draft shows a marked improvement over the previous >version and has made forward progress. Good work on this front! But >there is still plenty of room for improvement so here it goes - > >The high order bits: > >1. I like the fact that the draft focusses on one killer Conex >application which is traffic management; the remaining ones are >nice-to-have use cases. The structure that Alissa Cooper proposed >looks promising in bringing this feature out more explicitly. I was about to say the opposite to Alissa. Alissa's structure gives the "Other Use-Cases" a section each. I had deliberately kept them to bullet points within a section, because I wanted the reader to go away remembering one thing - this is primarily about improving traffic management with knock-on effects for LEDBAT & intra-class QoS. The rest is icing on the cake - not even icing - just little silver balls. >2. The draft starts out reading fresh, focussed and promising but >the quality deteriorates significantly as we go further on into >Sections 5, 6, 7. OK. >3. The language used throughout seems a bit too casual for an >Internet Draft. There's significant amount of work to be done in >terms of tidying up the writing. OK, but some examples will help me know what you call casual. >4. There was one thing that I was really looking forward to and >didn't find. There are two main ideas necessary to get across the >Conex idea - a) congestion volume matters, and b) knowing about >"rest-of-path" congestion or downstream congestion matters. The >draft brings out point (a) clearly, but surprisingly there is very >little on (b). I find that most folks new to Conex get point (a) >quickly and then are stuck thinking about why one would ever need >downstream congestion. If we focus on drop-only ConEx for initially deployment (ie without much/any ECN), ConEx gives whole path congestion, but not really downstream congestion. Downstream congestion relies on ECN as well as ConEx. And for single-network scenarios, whole path is probably sufficient. So, although I also think we should explain downstream congestion, it will only really get used briefly on the "Other use-case" of interconnection. Having said that, I want to improve that part of Concepts (section 2) about the split between upstream & downstream congestion, so this is a useful prompt. >------------ > >Nits in individual sections: > >1. Figure 1: Can be made simpler to parse without sacrificing >information. Has too many arrows currently. Ug. We've had a huge amount of discussion about this diag, and I thought we'd reached consensus. So now we have one individual contributor breaking the consensus who happens to also be the chair, whose role it is to call consensus ;) So I'm going to ask you to say more specifically what you don't like, and why everyone else is wrong ;) >2. Sec. 2 >"The blame for congestion..." >Accountability for congestion sounds better than blame. I know >there's extensive discussion on this in a separate thread... > >3. Sec. 2 >The introduction part of Sec. 2 (preceding the definitions in Sec. >2.1) is wordy/rambling and I don't see what its primary purpose is. >It also ends rather abruptly. However, the good parts are the >examples; they add a _lot_ of clarity. > >The definitions in Sec 2.1 by themselves do a great job of >introducing key Conex concepts. My suggestion would be to jump in >straight to the definitions and move some of the intro. text of Sec. >2 (and examples) to after the definitions - then it serves to nicely >connect the different concepts. Without the prose at the start of S2, I felt the definitions suddenly slapped you in the face, without saying why you needed to know them or how they related to the introduction you had just read. I can't find it now, but someone said the addition of this text was welcome in a document that claimed it was about concepts. >4. Sec 3.1 >"All of these current approaches suffer from some general >limitations. First, they introduce performance uncertainty...." >"Second, none of the approaches is able to make use of...." > >Switch order of the first and second reasons, as the second one is >by far the most important shortcoming of existing traffic management schemes. OK. >5. Sec. 5.1 >"the only reason their networks work as a commercial concern is that..." >You mean commercial success? Surely "work as a commercial concern" = "succeed commercially". I assume you don't mean we should change this to "work as a commercial success". I'm not sure what you are saying. >6. Sec 5.3. Consequence: User-Controlled Intra-Class Quality of Service (QoS) >This section is wordy and rambling - need a simpler way of directly >getting to the point. QoS part was quite bad in previous drafts and >it continues to be here. Actually, I didn't change it except for the heading. But I can have a go (or a volunteer?). >7. Another Consequence: Preventing Congestion Collapse. >I see the point that you are getting at, but this a very strong >claim with extremely little detail to back it up. Would it help just to add a caveat that this is believed to be true, but there is little evidence to back it up? >8. Sec. 6. Deployment Arrangements see new thread --> >9. Sec. 7 >The Section should be named 'Potential Issues' - keeps the section >focussed on real issues as opposed to those which are non-issues. The idea was to talk about things that might be issues, explain why they might be, but also why they might not be. This is defensive writing. People could otherwise skim and think "X is a potential issue with ConEx" when actually the section says it probably isn't. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_162620385==.ALT Content-Type: text/html; charset="us-ascii" Nandita,

At 04:25 20/07/2011, Nandita Dukkipati wrote:
Hi. Following are my comments on conex-concepts-uses draft -- as an individual contributor.

First of, the draft shows a marked improvement over the previous version and has made forward progress. Good work on this front! But there is still plenty of room for improvement so here it goes -

The high order bits:

1. I like the fact that the draft focusses on one killer Conex application which is traffic management; the remaining ones are nice-to-have use cases. The structure that Alissa Cooper proposed looks promising in bringing this feature out more explicitly.

I was about to say the opposite to Alissa. Alissa's structure gives the "Other Use-Cases" a section each. I had deliberately kept them to bullet points within a section, because I wanted the reader to go away remembering one thing - this is primarily about improving traffic management with knock-on effects for LEDBAT & intra-class QoS.

The rest is icing on the cake - not even icing - just little silver balls.


2. The draft starts out reading fresh, focussed and promising but the quality deteriorates significantly as we go further on into Sections 5, 6, 7.

OK.


3. The language used throughout seems a bit too casual for an Internet Draft. There's significant amount of work to be done in terms of tidying up the writing.

OK, but some examples will help me know what you call casual.


4. There was one thing that I was really looking forward to and didn't find. There are two main ideas necessary to get across the Conex idea - a) congestion volume matters, and b) knowing about "rest-of-path" congestion or downstream congestion matters. The draft brings out point (a) clearly, but surprisingly there is very little on (b). I find that most folks new to Conex get point (a) quickly and then are stuck thinking about why one would ever need downstream congestion.

If we focus on drop-only ConEx for initially deployment (ie without much/any ECN), ConEx gives whole path congestion, but not really downstream congestion. Downstream congestion relies on ECN as well as ConEx. And for single-network scenarios, whole path is probably sufficient.

So, although I also think we should explain downstream congestion, it will only really get used briefly on the "Other use-case" of interconnection.

Having said that, I want to improve that part of Concepts (section 2) about the split between upstream & downstream congestion, so this is a useful prompt.

------------

Nits in individual sections:

1. Figure 1: Can be made simpler to parse without sacrificing information. Has too many arrows currently.

Ug. We've had a huge amount of discussion about this diag, and I thought we'd reached consensus. So now we have one individual contributor breaking the consensus who happens to also be the chair, whose role it is to call consensus ;)

So I'm going to ask you to say more specifically what you don't like, and why everyone else is wrong ;)


2. Sec. 2
“The blame for congestion...”
Accountability for congestion sounds better than blame. I know there's extensive discussion on this in a separate thread...

3. Sec. 2
The introduction part of Sec. 2 (preceding the definitions in Sec. 2.1) is wordy/rambling and I don’t see what its primary purpose is. It also ends rather abruptly. However, the good parts are the examples; they add a _lot_ of clarity.

The definitions in Sec 2.1 by themselves do a great job of introducing key Conex concepts. My suggestion would be to jump in straight to the definitions and move some of the intro. text of Sec. 2 (and examples) to after the definitions - then it serves to nicely connect the different concepts.

Without the prose at the start of S2, I felt the definitions suddenly slapped you in the face, without saying why you needed to know them or how they related to the introduction you had just read. 

I can't find it now, but someone said the addition of this text was welcome in a document that claimed it was about concepts.

4. Sec 3.1
"All of these current approaches suffer from some general limitations. First, they introduce performance uncertainty...."
"Second, none of the approaches is able to make use of...."

Switch order of the first and second reasons, as the second one is by far the most important shortcoming of existing traffic management schemes.

OK.


5. Sec. 5.1
“the only reason their networks work as a commercial concern is that...”
You mean commercial success?

Surely "work as a commercial concern" = "succeed commercially".
I assume you don't mean we should change this to "work as a commercial success". I'm not sure what you are saying.

6. Sec 5.3.  Consequence: User-Controlled Intra-Class Quality of Service (QoS)
This section is wordy and rambling - need a simpler way of directly getting to the point. QoS part was quite bad in previous drafts and it continues to be here.

Actually, I didn't change it except for the heading. But I can have a go (or a volunteer?).


7. Another Consequence: Preventing Congestion Collapse.
I see the point that you are getting at, but this a very strong claim with extremely little detail to back it up.

Would it help just to add a caveat that this is believed to be true, but there is little evidence to back it up?


8. Sec. 6. Deployment Arrangements

see new thread -->


9. Sec. 7
The Section should be named 'Potential Issues' - keeps the section focussed on real issues as opposed to those which are non-issues.

The idea was to talk about things that might be issues, explain why they might be, but also why they might not be.

This is defensive writing. People could otherwise skim and think "X is a potential issue with ConEx" when actually the section says it probably isn't.


Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_162620385==.ALT-- From bob.briscoe@bt.com Wed Jul 20 10:29: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 EA26F21F8AF2 for ; Wed, 20 Jul 2011 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tqF2c8f9lLQ for ; Wed, 20 Jul 2011 10:29:11 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3179221F8AE6 for ; Wed, 20 Jul 2011 10:29:11 -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); Wed, 20 Jul 2011 18:29:09 +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); Wed, 20 Jul 2011 18:29:09 +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 1311182947852; Wed, 20 Jul 2011 18:29:07 +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 p6KHT6p7004858; Wed, 20 Jul 2011 18:29:06 +0100 Message-Id: <201107201729.p6KHT6p7004858@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Jul 2011 18:29:08 +0100 To: Nandita Dukkipati From: Bob Briscoe Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_162627295==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Jul 2011 17:29:09.0227 (UTC) FILETIME=[887C83B0:01CC4702] Cc: conex@ietf.org Subject: [conex] Moving Deployment Arrangements from 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: Wed, 20 Jul 2011 17:29:12 -0000 --=====================_162627295==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Nandita, Separating out Deployment Arrangements from your other email... At 04:25 20/07/2011, Nandita Dukkipati wrote: >8. Sec. 6. Deployment Arrangements >The list of bullet points is not that helpful. Needs some thought on >how one can articulate the deployment part without relying too much >on the mechanisms draft. Rich & I have had an idea: create a new draft about "single-network ConEx deployment". Then we can make concepts-uses and abstract-mech pre-requisite reading, and treat this subject properly. It could focus on the charter scenario (single receiver's network) and also give an intra-data-centre scenario (Murari said he was willing to co-author on this subject in Prague). It could also point to draft-kutscher-conex-mobile. Then we can have a brief section in concepts-uses pointing to this other draft and sumamrising it. Reason: Otherwise concepts-uses will have to have a huge lump of different material right near the end. we are going to have to explain policers and audit and protocol mechanisms in order to sensibly discuss incremental deployment. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_162627295==.ALT Content-Type: text/html; charset="us-ascii" Nandita,

Separating out Deployment Arrangements from your other email...

At 04:25 20/07/2011, Nandita Dukkipati wrote:

8. Sec. 6. Deployment Arrangements
The list of bullet points is not that helpful. Needs some thought on how one can articulate the deployment part without relying too much on the mechanisms draft.

Rich & I have had an idea: create a new draft about "single-network ConEx deployment". Then we can make concepts-uses and abstract-mech pre-requisite reading, and treat this subject properly.

It could focus on the charter scenario (single receiver's network) and also give an intra-data-centre scenario (Murari said he was willing to co-author on this subject in Prague). It could also point to draft-kutscher-conex-mobile.

Then we can have a brief section in concepts-uses pointing to this other draft and sumamrising it.

Reason: Otherwise concepts-uses will have to have a huge lump of different material right near the end. we are going to have to explain policers and audit and protocol mechanisms in order to sensibly discuss incremental deployment.


Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_162627295==.ALT-- From marcelo@it.uc3m.es Thu Jul 21 01:40: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 D3CC621F8906 for ; Thu, 21 Jul 2011 01:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.742 X-Spam-Level: X-Spam-Status: No, score=-106.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 PDUkPL4gZAbd for ; Thu, 21 Jul 2011 01:40:12 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3738821F889D for ; Thu, 21 Jul 2011 01:40:11 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 704E36C67F7 for ; Thu, 21 Jul 2011 10:39:58 +0200 (CEST) Message-ID: <4E27E5DE.3000408@it.uc3m.es> Date: Thu, 21 Jul 2011 10:39:58 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 'ConEx IETF list' 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.8.0.1017-18274.003 Subject: [conex] Call for adoption for draft-krishnan-conex-destopt-00 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, 21 Jul 2011 08:40:12 -0000 This is the call for adoption for draft-krishnan-conex-destopt-00 You can find it at: https://datatracker.ietf.org/doc/draft-krishnan-conex-destopt/ Please read it and comment whether you think we should adopt this doc as WG doc. We plan to discuss its adoption during the meeting as well and make a decision after the meeting. Regards, marcelo From wes@mti-systems.com Thu Jul 21 09:22: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 9D9E321F8A55 for ; Thu, 21 Jul 2011 09:22:52 -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 8spKQcihOHR3 for ; Thu, 21 Jul 2011 09:22:52 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2AA21F8779 for ; Thu, 21 Jul 2011 09:22:46 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6LGMjfg028975 for ; Thu, 21 Jul 2011 12:22:45 -0400 Authentication-Results: cm-omr9 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [63.226.32.150] ([63.226.32.150:13605] helo=[172.27.250.146]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 55/E1-30581-552582E4; Thu, 21 Jul 2011 12:22:45 -0400 Message-ID: <4E285254.7000204@mti-systems.com> Date: Thu, 21 Jul 2011 12:22:44 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: conex@ietf.org References: <4E27E5DE.3000408@it.uc3m.es> In-Reply-To: <4E27E5DE.3000408@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [conex] Call for adoption for draft-krishnan-conex-destopt-00 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, 21 Jul 2011 16:22:52 -0000 On 7/21/2011 4:39 AM, marcelo bagnulo braun wrote: > This is the call for adoption for draft-krishnan-conex-destopt-00 > > You can find it at: > > https://datatracker.ietf.org/doc/draft-krishnan-conex-destopt/ > > Please read it and comment whether you think we should adopt this doc as > WG doc. > We plan to discuss its adoption during the meeting as well and make a > decision after the meeting. > I think it's a good idea to adopt, and may be the most feasible approach based on the requirements. It does rely heavily on the companion draft-krishnan-conex-ipv6 document for rationale, and there are a couple things in that which might need to be added. I think one thing that bears a little bit of discussion in the companion draft-krishnan-conex-ipv6 document is whether the implementation of destination option processing in a conex router is possible in the fast-path when other destination options are used in conjunction, or whether there's some assumption about the number or order of destination options. There are two sub-goals of R-3 in that document which aren't currently clearly laid out, and those are (1) to not hit the slow-path on non-conex routers, and (2) to be implementable in the fast-path on conex routers. I think clarifying any assumptions there might be on the second part would be valuable. Another question is whether there's a requirement to be compatible with use of IPsec, which seems like it should at least be mentioned. -- Wes Eddy MTI Systems From marcelo@it.uc3m.es Thu Jul 21 09:31: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 7845F21F856D for ; Thu, 21 Jul 2011 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.724 X-Spam-Level: X-Spam-Status: No, score=-106.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 bbINiEuQO0e7 for ; Thu, 21 Jul 2011 09:31:09 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4EB21F8513 for ; Thu, 21 Jul 2011 09:31:09 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 705D0759B54 for ; Thu, 21 Jul 2011 18:31:08 +0200 (CEST) Message-ID: <4E28544C.9080509@it.uc3m.es> Date: Thu, 21 Jul 2011 18:31:08 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: conex@ietf.org References: <4E27E5DE.3000408@it.uc3m.es> <4E285254.7000204@mti-systems.com> In-Reply-To: <4E285254.7000204@mti-systems.com> 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.8.0.1017-18276.000 Subject: Re: [conex] Call for adoption for draft-krishnan-conex-destopt-00 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, 21 Jul 2011 16:31:10 -0000 Right, one thing i have been wondering is what to do with draft-krishnan-conex-ipv6 One option would be to publish it as informational for background (we don't have that item in our charter, but i would expect we can do that anyway) the other option would be to include it in the destopt draft as an appendix. My concern with this last approach is that people may object the draft due to discussion related to the material included in the appendix, which would be unfortunate. If people have opinions on this as well, it would be useful to know Regards, marcelo El 21/07/11 18:22, Wesley Eddy escribió: > On 7/21/2011 4:39 AM, marcelo bagnulo braun wrote: >> This is the call for adoption for draft-krishnan-conex-destopt-00 >> >> You can find it at: >> >> https://datatracker.ietf.org/doc/draft-krishnan-conex-destopt/ >> >> Please read it and comment whether you think we should adopt this doc as >> WG doc. >> We plan to discuss its adoption during the meeting as well and make a >> decision after the meeting. >> > > > I think it's a good idea to adopt, and may be the most feasible > approach based on the requirements. > > It does rely heavily on the companion draft-krishnan-conex-ipv6 > document for rationale, and there are a couple things in that > which might need to be added. > > I think one thing that bears a little bit of discussion in the > companion draft-krishnan-conex-ipv6 document is whether the > implementation of destination option processing in a conex router > is possible in the fast-path when other destination options are > used in conjunction, or whether there's some assumption about the > number or order of destination options. > > There are two sub-goals of R-3 in that document which aren't > currently clearly laid out, and those are (1) to not hit the > slow-path on non-conex routers, and (2) to be implementable > in the fast-path on conex routers. I think clarifying any > assumptions there might be on the second part would be valuable. > > Another question is whether there's a requirement to be > compatible with use of IPsec, which seems like it should at > least be mentioned. > From john@jlc.net Thu Jul 21 11:02:32 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 E037221F8757 for ; Thu, 21 Jul 2011 11:02:32 -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=[AWL=0.000, 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 9SNis7CU7Q-Y for ; Thu, 21 Jul 2011 11:02:32 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5555421F874E for ; Thu, 21 Jul 2011 11:02:32 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D17F433C28; Thu, 21 Jul 2011 14:02:31 -0400 (EDT) Date: Thu, 21 Jul 2011 14:02:31 -0400 From: John Leslie To: marcelo bagnulo braun Message-ID: <20110721180231.GA57285@verdi> References: <4E27E5DE.3000408@it.uc3m.es> <4E285254.7000204@mti-systems.com> <4E28544C.9080509@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E28544C.9080509@it.uc3m.es> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Call for adoption for draft-krishnan-conex-destopt-00 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, 21 Jul 2011 18:02:33 -0000 marcelo bagnulo braun wrote: > El 21/07/11 18:22, Wesley Eddy escribi?: >> On 7/21/2011 4:39 AM, marcelo bagnulo braun wrote: >> >>> This is the call for adoption for draft-krishnan-conex-destopt-00 >> >> I think it's a good idea to adopt, and may be the most feasible >> approach based on the requirements. >> >> It does rely heavily on the companion draft-krishnan-conex-ipv6 >> document for rationale, and there are a couple things in that >> which might need to be added. > > Right, one thing i have been wondering is what to do with > draft-krishnan-conex-ipv6 > > One option would be to publish it as informational for background (we > don't have that item in our charter, but i would expect we can do that > anyway) > the other option would be to include it in the destopt draft as an > appendix. My concern with this last approach is that people may object > the draft due to discussion related to the material included in the > appendix, which would be unfortunate. > > If people have opinions on this as well, it would be useful to know It would seem to me that the amount of text it actually depends on doesn't exceed 500 words, and would be easy enough to copy into conex-destopt. conex-destopt needs work in any case. We need to specify the three high-order bits of the option type; and IMHO we need to discuss option order -- since Destination Options _can_ occur in multiple times and may follow Authentication and Encapsulation headers. We probably need to discuss which routing nodes will process a ConEx Destination Option, since the IPv6 RFCs suggest these will be ignored until the packet reaches its Destination Address (but of course do nothing to prevent this). We will very likely recommend that a ConEx Destination Option be placed as early as possible in a Destination Option header but not preceding a Routing header (should such an animal ever happen!). -- John Leslie From john@jlc.net Thu Jul 21 11:32: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 3620021F85E3 for ; Thu, 21 Jul 2011 11:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_33=1, 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 jkIZCX0y18S0 for ; Thu, 21 Jul 2011 11:32:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 42FE621F8589 for ; Thu, 21 Jul 2011 11:32:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E0D0C33C2B; Thu, 21 Jul 2011 14:32:17 -0400 (EDT) Date: Thu, 21 Jul 2011 14:32:17 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110721183217.GB57285@verdi> References: <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> <002e01cc458a$8a39f800$9eade800$@com> <20110719120522.GE53567@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 21 Jul 2011 18:32:19 -0000 Mikael Abrahamsson wrote: > On Tue, 19 Jul 2011, John Leslie wrote: > >> But if an ingress policer is close enough to the source it needn't be >> flow-aware -- the user is in the best position to balance demands of >> different flows, and the policer merely needs to enforce an overall >> limit. > > I don't see the need for anything more than we have today then? What would > a conex enabled policer give if it's one policer per access port anyway? It would likely drop packets which exceed the Congestion-Expected allowance. (This is by no means the only possibility, but it seems the most likely.) > And how would it work when it's connected to an ISP<->ISP peering port? It would likely drop packets which exceed the Congestion-Expected allowance. (Here other options seem less unlikely...) >> If, OTOH, various users are aggregated before the ingress policer, >> the ingress policer is in a very poor position to sort them out -- >> especially with forging of source addresses being so easy. I think we're >> wasting our time to try. > > I always thought the policer acted on aggregation ports, ie for several > users. That is an implementation choice. There are setups where you can be quite confident which customer sent you the packet without depending on source address. And there are situations in which trusting the source address is reasonable. But IMHO, trying to distinguish flows would be a poor practice. YMMV, of course... >>> Show congestion to everybody, the user and ISP alike. >> >> Do you mean something beyond simply having in the IP packet in a >> well-known place? If so, what? > > I'm talking the congestion signals (re-ECN etc) that seems to be the > centarl goal of ConEx. They, by definition, will be in a well-known place in the packet. >>> I would like to see it also differentiate between self-congestion >>> (access link) and shared-link congestion (everything else than the >>> access link), but I have no idea how to do this. >> >> Neither do I... nor do I see any benefit. At any point, it's trivial >> to distinguish upstream from downstream. > > There is tremendous benefit from differentiating "my access link is > congesting because *I* am using it" to "my ISP doesn't have enough > capacity so because of *others* I can't use my full access speed", for > the user point of view. I can't think of a way to do that without cooperation by your ISP. However, the likes of DSLreports ought to be able to estimate congestion within your ISP... >> Oh, but we do. Any congestion on the return-path from receiver to >> sender is Somebody-Else's-Problem. > > I don't agree at all. If someone is dropping the traffic I'm about to > receive, I want to know about it. I think we have a failure-t'communicate here. Any transport receiver has to signal back to the sender, which may follow a congested path as well. How this is done is not a problem for ConEx to solve. >>> Should we give guidance to how the IP stack should expose this >>> information to the user? >> >> I don't understand the question. > > I want to empower the user with knowledge about congestion. I thought > this was a central goal of ConEx, to *expose* congestion. ... to the network layer: the application layer is awfully far removed from that... > >> Do you have suggestions on what would help? > > So, for core links, my suggestion is to use WRED and drop/set ECN at a > certain queue depth, for instance 20-30 ms queue depth. For access links, > I'd like to see "fair queuing" (RFC970) enabled on a lot more ADSL/cable > modems/Wifi routers, and also in hosts. > > RFC1254 also lists different ways of handling this. Generally, I'd say not > much of this is actually in use on the Internet today, 25+ years later :P > I run fair-queue on my access link at home, it works great. These seem reasonable, but not for ConEx to say... >> Ah, yes. Buffer tuning is fairly well understood by ISPs, but the >> distribution-of-information channels don't work well. :^( If you >> think ConEx could help, please say how! > > Er, considering basically NONE of the typical CPEs in use today does > anything other than FIFO with a lot of buffers, I'd say if the ISP > understands bufferbloat, they haven't communicated this to the purchasing > department who controls CPE purchases, because if they did, the typical > ADSL router would do better things than FIFO for upstream buffer > management. As I said, distribution-of-information channels don't work well. :^( > So I would like to have ConEx describe how buffering should be implemented > in all devices who might experience congestion on the outgoing interface > (hosts and routers, most likely different advice, ConEx perhaps should > define different classes of devices that should do different things), this > should be very good guidance going forward. Hmm... I don't see where that fits in our current documents. Perhaps you'd like to try writing an Internet Draft? -- John Leslie From swmike@swm.pp.se Thu Jul 21 12:03: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 AC61B21F84DA for ; Thu, 21 Jul 2011 12:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 5JNsrkTNY1Kc for ; Thu, 21 Jul 2011 12:03:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 16D7911E8071 for ; Thu, 21 Jul 2011 12:03:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0C6F09C; Thu, 21 Jul 2011 21:03:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0B2839A; Thu, 21 Jul 2011 21:03:07 +0200 (CEST) Date: Thu, 21 Jul 2011 21:03:07 +0200 (CEST) From: Mikael Abrahamsson To: John Leslie In-Reply-To: <20110721183217.GB57285@verdi> Message-ID: References: <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> <002e01cc458a$8a39f800$9eade800$@com> <20110719120522.GE53567@verdi> <20110721183217.GB57285@verdi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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, 21 Jul 2011 19:03:24 -0000 On Thu, 21 Jul 2011, John Leslie wrote: > ... to the network layer: the application layer is awfully far removed > from that... I'm not talking about the application layer, I'm talking about implementing metrics the network layer could present via a dashboard to the user. > These seem reasonable, but not for ConEx to say... If ISPs don't exmply ECN enabled handling of packets, isn't ConEx seriously crippled? > Hmm... I don't see where that fits in our current documents. Perhaps > you'd like to try writing an Internet Draft? I could write text to the list which could be the basis of a discussion if this would fit somewhere. I'm not going to start doing the whole RFC document formatting thing without knowing it's actually has a reasonable chance of getting used. I'll see when I have some time to write something. -- Mikael Abrahamsson email: swmike@swm.pp.se From acooper@cdt.org Fri Jul 22 11:22:54 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 7EFEE21F8A97 for ; Fri, 22 Jul 2011 11:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-bPshiPljnm for ; Fri, 22 Jul 2011 11:22:54 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id D39A321F8A91 for ; Fri, 22 Jul 2011 11:22:53 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 22 Jul 2011 14:22:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <201107191629.p6JGTQge031996@bagheera.jungle.bt.co.uk> Date: Fri, 22 Jul 2011 19:22:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D74F40D-6859-47A6-886A-9ED1049EACB2@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> <201107181838.p6IIcLbV027438@bagheera.jungle.bt.co.uk> <73F0F934-B777-465D-8A23-58826F21292E@cdt.org> <201107191629.p6JGTQge031996@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 22 Jul 2011 18:22:54 -0000 Hi Bob, On Jul 19, 2011, at 5:29 PM, Bob Briscoe wrote: >> > >> > Then, what are you implying about the non-goals/misconceptions = subsection, which you've not mentioned? >>=20 >> Nothing. I find it confusing to start the document by saying what it = doesn't do, that's all. >=20 > We're 6 pages into the text by now (not incl. the 2 pages of = preamble). >=20 > Do you really mean "confusing", or just unnecessary? I'm just trying to give a sense of my experience as the reader, having = not looked at this for a number of months. I was confused to be reading = about what conex does not do so early in the document, before the use = cases had been fully described. Phil and Michael have likewise suggested = that this section belongs at the end. With that said, regardless of where it appears in the document, it might = still create some confusion to spend two paragraphs of exposition about = why per-flow fairness is generally harmful and one paragraph explaining = why eliminating all congestion is not optimal without linking that = explanation to conex. I think the non-goals (which, at my count, are (1) = fine-grained congestion control, (2) per-flow fairness, (3) substitution = for capacity planning, (4) elimination of all congestion, and (5) = mitigation of self-congestion) could be stated more succinctly. Alissa >=20 > Given how many people on this list have assumed some non-goals are = goals, a number of people have been saying (including me) that we need = to explicitly unhitch new readers from some of the more common = preconceptions they seem to have. >=20 > I agree this shouldn't be done before we've said what ConEx is, but = that's why it's positioned here, after the Intro, Concepts and = Definitions, at the point where the reader should now 'get it', before = reading on for the detail. >=20 > Still disagree? >=20 >=20 > Bob >=20 >=20 >> Alissa >>=20 >> > >> > I'm about to go offline, so will continue in the morning... >> > >> > >> > Bob >> > >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT Innovate & Design >> > >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 From acooper@cdt.org Fri Jul 22 11:23:32 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 ECE9A21F8A67 for ; Fri, 22 Jul 2011 11:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsM1ILbLzLvu for ; Fri, 22 Jul 2011 11:23:32 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id F2F6221F88A0 for ; Fri, 22 Jul 2011 11:23:31 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 22 Jul 2011 14:23:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <201107201707.p6KH7LPR004722@bagheera.jungle.bt.co.uk> Date: Fri, 22 Jul 2011 19:23:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <371A15DE-0BCF-45D2-88A6-38D2D2B9A0FD@cdt.org> References: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> <201107201707.p6KH7LPR004722@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1084) Cc: conex@ietf.org Subject: Re: [conex] "traffic management" 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, 22 Jul 2011 18:23:33 -0000 Hi Bob, I think if John's suggestion in this thread about the text in 3.1 is = followed, that would help to clear up the endpoint-versus-network = distinction. There are a number of places in the document where I do = think it is implied that traffic management is a network operator = function (e.g., second-to-last para on page 4, first use case in 5.4), = so the 3.1 clarification would be consistent with those. A definition entry, if it made clear that the term applies to managing = traffic for numerous purposes other than managing congestion, could be = helpful. That might serve to counter the implication of phrases like = this one in 5.1, which could be understood to mean that the goal of = traffic management is only performance-driven: "In order to ensure all = customers get decent performance from the network, they subject the = "heaviest" customers to some form of traffic management." Alissa On Jul 20, 2011, at 6:07 PM, Bob Briscoe wrote: > Alissa, >=20 > Isn't traffic management surely a very general term that means = "managing traffic" (self-evidently). It doesn't have to imply who is = managing traffic. The word 'traffic' gives it an implication of managing = the bulk of traffic, not individual flows. So it would generally be = associated with an operator managing traffic. But it could also mean the = overall outcome of an end-system doing congestion control on all its = flows. >=20 > IOW, it's a useful general term for a range of functions that alter = the overall profile of traffic. >=20 > We certainly have to use the term traffic management when talking = about all the things operators do today (partly because they aren't = directly managing congestion, and in some cases they aren't even trying = to indirectly manage congestion). >=20 > We can say that ConEx allows operators to focus their traffic = management on managing congestion. But I don't think we should then call = it congestion management, because that would risk being confused with = end-system congestion control. >=20 > Do you think a definition entry for this would help? Or if it said = traffic management is managing traffic, would it just add empty bytes to = the draft? >=20 > [BTW, in public policy circles, they use the phrase network management = to mean operator's traffic management. I tell them this is liable to = misinterpretation in the industry.] >=20 >=20 >=20 > Bob >=20 > At 18:11 18/07/2011, Alissa Cooper wrote: >> I've been reviewing draft-ietf-conex-concepts-uses-02 and may send a = few emails about different things. >>=20 >> I'm wondering what is meant by "traffic management" as the term is = used in the draft. Sometimes it seems to encompass only actions that = operators might take; other times it seems to also include = endpoint-controlled management of congestion (e.g., in section 3). = Sometimes it seems to be used in a way that is synonymous with = "congestion management"; other times it seems to take on the more = expansive connotation (that I often find used in the UK), encompassing = motivations beyond mitigating congestion (e.g., deferring capacity = investment by reducing peak-hour usage). >>=20 >> If what we're really talking about is the management of congestion by = network operators, it might be better to call it "congestion management" = and only use the term when referring to network-based management. If = some more expansive concept is intended, that probably needs to be = clarified. >>=20 >> Alissa >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 From nanditad@google.com Sat Jul 23 11:32:15 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 0CB6521F865B for ; Sat, 23 Jul 2011 11:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4gYVkaj+Ihm for ; Sat, 23 Jul 2011 11:32:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C643321F863E for ; Sat, 23 Jul 2011 11:32:13 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p6NIWCHs026553 for ; Sat, 23 Jul 2011 11:32:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311445933; bh=JpI0Z5hwenTxLClrOATE0wcRgbU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=EN6+sf+V1KgfBlt03YliiDXHgOxYVB1MgmRSkq/u7sQAuBfy05JTaCv9zH46XKsCU h9yC0wuyG0VSiwlC3rw4w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=xRMIE9h7JE2vv5RFH3WEtyBsOjRr3uy1RdPIDlZ2bFs+SEsHs31cE7uTY6owXDEGv TV3jK+OOPd5y+th1j++WQ== Received: from yxk38 (yxk38.prod.google.com [10.190.3.166]) by kpbe12.cbf.corp.google.com with ESMTP id p6NIWBOk005630 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 23 Jul 2011 11:32:11 -0700 Received: by yxk38 with SMTP id 38so2147885yxk.2 for ; Sat, 23 Jul 2011 11:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWEMRjKbylWF2zqD1pcIHKx/dXE5oMigb8QmMMp0YwM=; b=KJKA0ed/a1lZo/KbdDqwTEhx95WAaAD7hQ+OIFFsJBKLatijbWQ2hT9S62acPgFxBb uccNl2Ika8rVruKZPSbg== MIME-Version: 1.0 Received: by 10.150.175.13 with SMTP id x13mr2941002ybe.355.1311445931041; Sat, 23 Jul 2011 11:32:11 -0700 (PDT) Received: by 10.150.98.14 with HTTP; Sat, 23 Jul 2011 11:32:10 -0700 (PDT) In-Reply-To: <201107201728.p6KHSxiY004854@bagheera.jungle.bt.co.uk> References: <201107201728.p6KHSxiY004854@bagheera.jungle.bt.co.uk> Date: Sat, 23 Jul 2011 11:32:10 -0700 Message-ID: From: Nandita Dukkipati To: Bob Briscoe Content-Type: multipart/alternative; boundary=000e0cd76234dca4d604a8c0cc36 X-System-Of-Record: true Cc: conex@ietf.org Subject: Re: [conex] Comments on 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, 23 Jul 2011 18:32:15 -0000 --000e0cd76234dca4d604a8c0cc36 Content-Type: text/plain; charset=ISO-8859-1 Bob, > 1. I like the fact that the draft focusses on one killer Conex application > which is traffic management; the remaining ones are nice-to-have use cases. > The structure that Alissa Cooper proposed looks promising in bringing this > feature out more explicitly. > > I was about to say the opposite to Alissa. Alissa's structure gives the > "Other Use-Cases" a section each. I had deliberately kept them to bullet > points within a section, because I wanted the reader to go away remembering > one thing - this is primarily about improving traffic management with > knock-on effects for LEDBAT & intra-class QoS. > The appeal in Alissa's proposed structure is its sections explicitly titled "Core Use Case" and "Other Use Cases". Can't make it more direct than that as to what the main use case is and what the others are - it's all there in the section headings! > 4. There was one thing that I was really looking forward to and didn't > find. There are two main ideas necessary to get across the Conex idea - a) > congestion volume matters, and b) knowing about "rest-of-path" congestion or > downstream congestion matters. The draft brings out point (a) clearly, but > surprisingly there is very little on (b). I find that most folks new to > Conex get point (a) quickly and then are stuck thinking about why one would > ever need downstream congestion. > > > If we focus on drop-only ConEx for initially deployment (ie without > much/any ECN), ConEx gives whole path congestion, but not really downstream > congestion. Downstream congestion relies on ECN as well as ConEx. And for > single-network scenarios, whole path is probably sufficient. > > So, although I also think we should explain downstream congestion, it will > only really get used briefly on the "Other use-case" of interconnection. > > Having said that, I want to improve that part of Concepts (section 2) about > the split between upstream & downstream congestion, so this is a useful > prompt. > Without getting into drop-only/ECN Conex, how would you explain to someone the basic question - what is the fundamental reason that a network node experiencing congestion requires to know the whole path congestion as opposed to just its local congestion volume for some granularities of traffic? Put in another way, if every node in the network is aware locally of the congestion volume for some traffic granulaties (through some means other than Conex), why wouldn't this suffice for congestion management? We have discussed this question before... but I just have to wonder if the answer is so obvious that it doesn't figure in the draft or is there some other reason? Nits in individual sections: > > 1. Figure 1: Can be made simpler to parse without sacrificing information. > Has too many arrows currently. > > > Ug. We've had a huge amount of discussion about this diag, and I thought > we'd reached consensus. So now we have one individual contributor breaking > the consensus who happens to also be the chair, whose role it is to call > consensus ;) > > So I'm going to ask you to say more specifically what you don't like, and > why everyone else is wrong ;) > > As I said, this is a nit. There's consensus on it, so let's leave it as is. 7. Another Consequence: Preventing Congestion Collapse. I see the point that you are getting at, but this a very strong claim with extremely little detail to back it up. Would it help just to add a caveat that this is believed to be true, but > there is little evidence to back it up? > That doesn't help at all. If we can't find a good reason to back it up, we shouldn't have this point here. > 9. Sec. 7 > > The Section should be named 'Potential Issues' - keeps the section focussed > on real issues as opposed to those which are non-issues. > > > The idea was to talk about things that might be issues, explain why they > might be, but also why they might not be. > > This is defensive writing. People could otherwise skim and think "X is a > potential issue with ConEx" when actually the section says it probably > isn't. > ok, makes sense. Nandita --000e0cd76234dca4d604a8c0cc36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Bob,=A0
1. I like the fact that the draft focusses on one killer Conex application which is traffic management; the remaining ones are nice-to-have use cases. The structure that Alissa Cooper proposed looks promising in bringing this feature out more explicitly.
I= was about to say the opposite to Alissa. Alissa's structure gives the "Other Use-Cases" a section each. I had deliberately kept them to bullet points within a section, because I wanted the reader to go away remembering one thing - this is primarily about improving traffic management with knock-on effects for LEDBAT & intra-class QoS.

The = appeal in Alissa's proposed structure is its sections explicitly titled= "Core Use Case" and "Other Use Cases". Can't make = it more direct than that as to what the main use case is and what the other= s are - it's all there in the section headings!
=A0
4. There was one thing that I was really looking forward to and didn't find. There are two main ideas necessary to get across the Conex idea - a) congestion volume matters, and b) knowing about "rest-of-path" congestion or downstream congestion matters. The draft brings out point (a) clearly, but surprisingly there is very little on (b). I find that most folks new to Conex get point (a) quickly and then are stuck thinking about why one would ever need downstream congestion.

If we focus on drop-only ConEx for initially deployment (ie without much/any ECN), ConEx gives whole path congestion, but not really downstream congestion. Downstream congestion relies on ECN as well as ConEx. And for single-network scenarios, whole path is probably sufficient.

So, although I also think we should explain downstream congestion, it will only really get used briefly on the "Other use-case" of interconnection.

Having said that, I want to improve that part of Concepts (section 2) about the split between upstream & downstream congestion, so this is a useful prompt.

Without getting into= drop-only/ECN Conex, how would you explain to someone the basic question -= what is the fundamental reason that a network node experiencing congestion= requires to know the whole path congestion as opposed to just its local co= ngestion volume for some granularities of traffic? Put in another way, if e= very node in the network is aware locally of the congestion volume for some= traffic granulaties (through some means other than Conex), why wouldn'= t this suffice for congestion management?

We have discussed this question before... but I just ha= ve to wonder if the answer is so obvious that it doesn't figure in the = draft or is there some other reason?

Nits in individual section= s:

1. Figure 1: Can be made simpler to parse without sacrificing information. Has too many arrows currently.

Ug. We've had a huge amount of discussion about this diag, and I though= t we'd reached consensus. So now we have one individual contributor breaking the consensus who happens to also be the chair, whose role it is to call consensus ;)

So I'm going to ask you to say more specifically what you don't lik= e, and why everyone else is wrong ;)


As I said, this is a nit. There's consensus on it,= so let's leave it as is.=A0
7. Another Consequence: Preventing Congestion Collapse.
I see the point = that you are getting at, but this a very strong claim with extremely little= detail to back it up.
Would it help just to add a caveat that this is believed to be true, b= ut there is little evidence to back it up?

That doesn't help at all. If we can't find a good reason to back= it up, we shouldn't have this point here.
=A0
9. Sec. 7
The Section should be named 'Potential Issues' - keeps the section focussed on real issues as opposed to those which are non-issues.

The idea was to talk about things that might be issues, explain why they might be, but also why they might not be.

This is defensive writing. People could otherwise skim and think "X is a potential issue with ConEx" when actually the section says it probably isn't.

ok, makes sen= se.

Nandita
--000e0cd76234dca4d604a8c0cc36-- From nanditad@google.com Sat Jul 23 11:46: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 E596E21F8B07 for ; Sat, 23 Jul 2011 11:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fTIcuoxtDSr for ; Sat, 23 Jul 2011 11:46:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0C21F8544 for ; Sat, 23 Jul 2011 11:46:03 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p6NIk2oZ029683 for ; Sat, 23 Jul 2011 11:46:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311446762; bh=GkyWXyOcWeiY75QruZI57cIE9Wo=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=sNz+rOyN30YuYpcRMBDcgr78bmQnoTBRSzQ75MwFZdIZLbmUhC4dYlacUEsmKFI4P NAxBzmRjYW/TRsZ9N1nxg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=UbHWHR8MJu+e/EcwEv42nTGoLKJobW6HYDq66Te6wuBZBIYr8ADo2Jz3XmhqQhYns H9IRzEv+vQwfaRPETF6KQ== Received: from yic13 (yic13.prod.google.com [10.243.65.141]) by hpaq6.eem.corp.google.com with ESMTP id p6NIk02U002304 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 23 Jul 2011 11:46:01 -0700 Received: by yic13 with SMTP id 13so2106367yic.13 for ; Sat, 23 Jul 2011 11:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HfgoLhPDCVgtYsu/BhCIDbvI/vBUdEvfV3dincQ5Z2k=; b=jQIE+Xlt9R+kLzsBR4GwdHYm8+SpLU5/RQ/Es0PxsvyXi7rYs8uMFnSMhGnZ/tx7lV XsRhbwer57G9GWq29xwA== MIME-Version: 1.0 Received: by 10.151.15.5 with SMTP id s5mr3222846ybi.241.1311446759820; Sat, 23 Jul 2011 11:45:59 -0700 (PDT) Received: by 10.150.98.14 with HTTP; Sat, 23 Jul 2011 11:45:59 -0700 (PDT) Date: Sat, 23 Jul 2011 11:45:59 -0700 Message-ID: From: Nandita Dukkipati To: Matthew Mathis , Bob Briscoe Content-Type: multipart/alternative; boundary=000e0cd6ed5842ce3404a8c0fe67 X-System-Of-Record: true Cc: conex@ietf.org Subject: [conex] draft-ietf-conex-abstract-mech reads well 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, 23 Jul 2011 18:46:04 -0000 --000e0cd6ed5842ce3404a8c0fe67 Content-Type: text/plain; charset=ISO-8859-1 Just completed reading this one. The draft reads well, just keeps getting better in each iteration... I have no major comments, but addressing the ones raised in the ML (by Marcelo and others) will make it even stronger of course. Nandita --000e0cd6ed5842ce3404a8c0fe67 Content-Type: text/html; charset=ISO-8859-1 Just completed reading this one. The draft reads well, just keeps getting better in each iteration... I have no major comments, but addressing the ones raised in the ML (by Marcelo and others) will make it even stronger of course.

Nandita
--000e0cd6ed5842ce3404a8c0fe67-- From marcelo@it.uc3m.es Mon Jul 25 02: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 B119F21F8567 for ; Mon, 25 Jul 2011 02:45:30 -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 88voBBLUyUds for ; Mon, 25 Jul 2011 02:45:30 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDAB21F874B for ; Mon, 25 Jul 2011 02:45:29 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (modemcable091.86-81-70.mc.videotron.ca [70.81.86.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 09540BFDFBA for ; Mon, 25 Jul 2011 11:45:22 +0200 (CEST) Message-ID: <4E2D3B2D.4060401@it.uc3m.es> Date: Mon, 25 Jul 2011 11:45:17 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: 'ConEx IETF list' 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.8.0.1017-18282.006 Subject: [conex] slides 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, 25 Jul 2011 09:45:30 -0000 Presenters plase send Nandita and me the slides thanks, marcelo From bob.briscoe@bt.com Mon Jul 25 19:39:37 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 705D521F885C for ; Mon, 25 Jul 2011 19:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 ZJdyLmS17i8F for ; Mon, 25 Jul 2011 19:39:36 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 348DF21F885A for ; Mon, 25 Jul 2011 19:39:36 -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, 26 Jul 2011 03:39:34 +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, 26 Jul 2011 03:39:34 +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 1311647973429; Tue, 26 Jul 2011 03:39:33 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.208.19]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6Q2dSqf004477; Tue, 26 Jul 2011 03:39:29 +0100 Message-Id: <201107260239.p6Q2dSqf004477@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Jul 2011 03:38:20 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <371A15DE-0BCF-45D2-88A6-38D2D2B9A0FD@cdt.org> References: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> <201107201707.p6KH7LPR004722@bagheera.jungle.bt.co.uk> <371A15DE-0BCF-45D2-88A6-38D2D2B9A0FD@cdt.org> 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 Jul 2011 02:39:34.0470 (UTC) FILETIME=[41216E60:01CC4B3D] Cc: conex@ietf.org Subject: Re: [conex] "traffic management" 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: Tue, 26 Jul 2011 02:39:37 -0000 Alissa, At 19:23 22/07/2011, Alissa Cooper wrote: >Hi Bob, > >I think if John's suggestion in this thread about the text in 3.1 is >followed, that would help to clear up the endpoint-versus-network distinction. I assume you mean this: At 19:13 18/07/2011, John Leslie wrote: >>" Since then capacity has been shared by a mix of traffic management >>" approaches, partly network-based (weighted round-robin scheduling, >>" weighted fair queuing, etc) and partly host-based (TCP). >> >> This looks like a wordsmithing oversight: I think Bob meant "mix >>of congestion management and traffic management approches". Well, if we define traffic management as the superset of ways that traffic is managed, including (rather than excluding) congestion management, then the original is OK, and it wouldn't make sense to say "a mix of congestion management and traffic management", just as it wouldn't make sense to say "a mix of oranges and fruit". >There are a number of places in the document where I do think it is >implied that traffic management is a network operator function >(e.g., second-to-last para on page 4, first use case in 5.4), so the >3.1 clarification would be consistent with those. Neither case implies traffic management is *only* something operators do. Again, if traffic management implies nothing about who is doing the traffic management, there will be places where we talk about operators doing it, but that doesn't imply we're saying no-one else can. Similarly, if I say 40% of women eat an orange per day, I'm not saying men don't eat oranges. >A definition entry, if it made clear that the term applies to >managing traffic for numerous purposes other than managing >congestion, could be helpful. That might serve to counter the >implication of phrases like this one in 5.1, which could be >understood to mean that the goal of traffic management is only >performance-driven: "In order to ensure all customers get decent >performance from the network, they subject the "heaviest" customers >to some form of traffic management." I'm happy to add a definition for traffic management, but as I said, its value won't be in the definition (managing traffic) but in riders about what it's not: it's not only performance-driven and it's often but not necessarily operator driven. Bob >Alissa > >On Jul 20, 2011, at 6:07 PM, Bob Briscoe wrote: > > > Alissa, > > > > Isn't traffic management surely a very general term that means > "managing traffic" (self-evidently). It doesn't have to imply who > is managing traffic. The word 'traffic' gives it an implication of > managing the bulk of traffic, not individual flows. So it would > generally be associated with an operator managing traffic. But it > could also mean the overall outcome of an end-system doing > congestion control on all its flows. > > > > IOW, it's a useful general term for a range of functions that > alter the overall profile of traffic. > > > > We certainly have to use the term traffic management when talking > about all the things operators do today (partly because they aren't > directly managing congestion, and in some cases they aren't even > trying to indirectly manage congestion). > > > > We can say that ConEx allows operators to focus their traffic > management on managing congestion. But I don't think we should then > call it congestion management, because that would risk being > confused with end-system congestion control. > > > > Do you think a definition entry for this would help? Or if it > said traffic management is managing traffic, would it just add > empty bytes to the draft? > > > > [BTW, in public policy circles, they use the phrase network > management to mean operator's traffic management. I tell them this > is liable to misinterpretation in the industry.] > > > > > > > > Bob > > > > At 18:11 18/07/2011, Alissa Cooper wrote: > >> I've been reviewing draft-ietf-conex-concepts-uses-02 and may > send a few emails about different things. > >> > >> I'm wondering what is meant by "traffic management" as the term > is used in the draft. Sometimes it seems to encompass only actions > that operators might take; other times it seems to also include > endpoint-controlled management of congestion (e.g., in section 3). > Sometimes it seems to be used in a way that is synonymous with > "congestion management"; other times it seems to take on the more > expansive connotation (that I often find used in the UK), > encompassing motivations beyond mitigating congestion (e.g., > deferring capacity investment by reducing peak-hour usage). > >> > >> If what we're really talking about is the management of > congestion by network operators, it might be better to call it > "congestion management" and only use the term when referring to > network-based management. If some more expansive concept is > intended, that probably needs to be clarified. > >> > >> Alissa > >> _______________________________________________ > >> 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 Mon Jul 25 20:53: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 2126711E80FF for ; Mon, 25 Jul 2011 20:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, 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 H1TRzEfzsuNA for ; Mon, 25 Jul 2011 20:53:37 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC9911E80FE for ; Mon, 25 Jul 2011 20:53:37 -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); Tue, 26 Jul 2011 04:53:35 +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, 26 Jul 2011 04:53:36 +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 1311652415162; Tue, 26 Jul 2011 04:53:35 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.208.19]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6Q3rWfN005087; Tue, 26 Jul 2011 04:53:33 +0100 Message-Id: <201107260353.p6Q3rWfN005087@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Jul 2011 04:53:30 -0400 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <8D74F40D-6859-47A6-886A-9ED1049EACB2@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> <201107181838.p6IIcLbV027438@bagheera.jungle.bt.co.uk> <73F0F934-B777-465D-8A23-58826F21292E@cdt.org> <201107191629.p6JGTQge031996@bagheera.jungle.bt.co.uk> <8D74F40D-6859-47A6-886A-9ED1049EACB2@cdt.org> 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 Jul 2011 03:53:36.0055 (UTC) FILETIME=[98858470:01CC4B47] Cc: ConEx IETF list Subject: Re: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC 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, 26 Jul 2011 03:53:38 -0000 Alissa, OK, message received. I'd like to try what Phil suggested: move it to later (and OK, shorter), but advertise it at the end of the concepts section, using the five bullets you list. Reason: You, Phil & Michael don't hold these misconceptions. But anyone who does (which is going to be most people) is going to have got through the concepts section not understanding why/what is going on. Bob At 14:22 22/07/2011, Alissa Cooper wrote: >Hi Bob, > >On Jul 19, 2011, at 5:29 PM, Bob Briscoe wrote: > >> > > >> > Then, what are you implying about the non-goals/misconceptions > subsection, which you've not mentioned? > >> > >> Nothing. I find it confusing to start the document by saying > what it doesn't do, that's all. > > > > We're 6 pages into the text by now (not incl. the 2 pages of preamble). > > > > Do you really mean "confusing", or just unnecessary? > >I'm just trying to give a sense of my experience as the reader, >having not looked at this for a number of months. I was confused to >be reading about what conex does not do so early in the document, >before the use cases had been fully described. Phil and Michael have >likewise suggested that this section belongs at the end. > >With that said, regardless of where it appears in the document, it >might still create some confusion to spend two paragraphs of >exposition about why per-flow fairness is generally harmful and one >paragraph explaining why eliminating all congestion is not optimal >without linking that explanation to conex. I think the non-goals >(which, at my count, are (1) fine-grained congestion control, (2) >per-flow fairness, (3) substitution for capacity planning, (4) >elimination of all congestion, and (5) mitigation of >self-congestion) could be stated more succinctly. > >Alissa > > > > > Given how many people on this list have assumed some non-goals > are goals, a number of people have been saying (including me) that > we need to explicitly unhitch new readers from some of the more > common preconceptions they seem to have. > > > > I agree this shouldn't be done before we've said what ConEx is, > but that's why it's positioned here, after the Intro, Concepts and > Definitions, at the point where the reader should now 'get it', > before reading on for the detail. > > > > Still disagree? > > > > > > Bob > > > > > >> Alissa > >> > >> > > >> > I'm about to go offline, so will continue in the morning... > >> > > >> > > >> > Bob > >> > > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT Innovate & Design > >> > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Jul 25 22:18: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 865B621F8B66 for ; Mon, 25 Jul 2011 22:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, J_BACKHAIR_33=1, J_CHICKENPOX_93=0.6, 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 m-ImloIWdBiQ for ; Mon, 25 Jul 2011 22:18:32 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id A085821F8B3C for ; Mon, 25 Jul 2011 22:18:31 -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, 26 Jul 2011 06:18:30 +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, 26 Jul 2011 06:18:29 +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 1311657509114; Tue, 26 Jul 2011 06:18:29 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.208.19]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6Q5IQlC005323; Tue, 26 Jul 2011 06:18:27 +0100 Message-Id: <201107260518.p6Q5IQlC005323@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Jul 2011 06:18:23 -0400 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: <20110721183217.GB57285@verdi> References: <9510D26531EF184D9017DF24659BB87F32E2D33CE2@EMV65-UKRD.domain1.systemhost.net> <7.1.0.9.2.20110707180350.078f2a60@bt.com> <201107111714.p6BHEG5t016930@bagheera.jungle.bt.co.uk> <20110713163314.GE2822@verdi> <201107181828.p6IISmh9027403@bagheera.jungle.bt.co.uk> <20110718193536.GD53567@verdi> <002e01cc458a$8a39f800$9eade800$@com> <20110719120522.GE53567@verdi> <20110721183217.GB57285@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: 26 Jul 2011 05:18:29.0965 (UTC) FILETIME=[74BA7FD0:01CC4B53] Cc: conex@ietf.org Subject: Re: [conex] New concepts text 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: Tue, 26 Jul 2011 05:18:33 -0000 Mikael, At 14:32 21/07/2011, John Leslie wrote: >Mikael Abrahamsson wrote: > > On Tue, 19 Jul 2011, John Leslie wrote: > > > >> But if an ingress policer is close enough to the source it needn't be > >> flow-aware -- the user is in the best position to balance demands of > >> different flows, and the policer merely needs to enforce an overall > >> limit. > > > > I don't see the need for anything more than we have today then? What would > > a conex enabled policer give if it's one policer per access port anyway? > > It would likely drop packets which exceed the Congestion-Expected >allowance. (This is by no means the only possibility, but it seems the >most likely.) > > > And how would it work when it's connected to an ISP<->ISP peering port? > > It would likely drop packets which exceed the Congestion-Expected >allowance. (Here other options seem less unlikely...) > > >> If, OTOH, various users are aggregated before the ingress policer, > >> the ingress policer is in a very poor position to sort them out -- > >> especially with forging of source addresses being so easy. I think we're > >> wasting our time to try. > > > > I always thought the policer acted on aggregation ports, ie for several > > users. > > That is an implementation choice. There are setups where you can be >quite confident which customer sent you the packet without depending on >source address. And there are situations in which trusting the source >address is reasonable. But IMHO, trying to distinguish flows would be >a poor practice. YMMV, of course... The idea is for ConEx info to be used to 'sanction' the immediately connected entity, not the entities the other side of it. Then the immediately connected entity can sanction its immediately connected entities if it so wishes. If you do something else, it's up to you, but you're relying on network layer source addresses, and wasting a system (ConEx) that was deliberately arranged not to have to. However, the deployment story for ConEx is a single network first, where this issue doesn't arise. It's only worth using ConEx in multiple networks once you have ECN as well (as you yourself have also pointed out). > >>> Show congestion to everybody, the user and ISP alike. > >> > >> Do you mean something beyond simply having in the IP packet in a > >> well-known place? If so, what? > > > > I'm talking the congestion signals (re-ECN etc) that seems to be the > > centarl goal of ConEx. > > They, by definition, will be in a well-known place in the packet. > > >>> I would like to see it also differentiate between self-congestion > >>> (access link) and shared-link congestion (everything else than the > >>> access link), but I have no idea how to do this. > >> > >> Neither do I... nor do I see any benefit. At any point, it's trivial > >> to distinguish upstream from downstream. > > > > There is tremendous benefit from differentiating "my access link is > > congesting because *I* am using it" to "my ISP doesn't have enough > > capacity so because of *others* I can't use my full access speed", for > > the user point of view. > > I can't think of a way to do that without cooperation by your ISP. >However, the likes of DSLreports ought to be able to estimate congestion >within your ISP... In the downstream, DSL is arranged so that the per-CVLAN queue in the BRAS models that customer's DSL line and drops packets as if it had a capacity equal to the line. Then separately there is the scheduling to share the backhaul network (the link between the BRAS and the DSLAM), which is typically a WRR scheduler also in the BRAS. In a single network scenario, we can assume there is little loss upstream of the BRAS if the traffic is coming from a data centre over a core network. Therefore, for each customer, subtracting loss in the WRR queue at the BRAS from their ConEx markings will give the loss in the (modelled) access line. If you also had ECN in the upstream access you can do similar tricks in the upstream direction. But even without ECN, at least doing it in the downstream is one better than anything else that can't do it at all. However, I also wanted to interject here for a more basic explanation. Congestion is a property of a link or path that is the same for everyone using it. Whereas congestion-volume is a property of each user's traffic, measured by counting ConEx markings on only the packets of that user. ConEx isn't merely trying to find how congested a link is. We can already do that. ConEx is trying to attribute which traffic contributed how much to the congestion. If Alice sends all her volume when the link is congested while Bob sends the same volume when it isn't, the DSL reports could be the same, but the congestion-volumes will be very different. > >> Oh, but we do. Any congestion on the return-path from receiver to > >> sender is Somebody-Else's-Problem. > > > > I don't agree at all. If someone is dropping the traffic I'm about to > > receive, I want to know about it. > > I think we have a failure-t'communicate here. Any transport receiver >has to signal back to the sender, which may follow a congested path as >well. How this is done is not a problem for ConEx to solve. I agre it's not our direct problem. But in the design of the accurate transport feedback we have ensured that the feedback info is robust to ack losses. But that's probably just confusing your point, which is in general true. > >>> Should we give guidance to how the IP stack should expose this > >>> information to the user? > >> > >> I don't understand the question. > > > > I want to empower the user with knowledge about congestion. I thought > > this was a central goal of ConEx, to *expose* congestion. Quoting conex-concepts-uses: "2.2. Non-Goals of ConEx and Common Misconceptions Congestion exposure is about the transport sender exposing congestion to the network, not the other way round. That would not make sense given by design the transport endpoints already handle congestion in the TCP/IP protocol suite. " Nonetheless, by exposing congestion to the operator, it makes the operator able to do something about the user's congestion, which motivates {apps|transport protocols|the user} to do something with their pre-existing knowledge of congestion. > ... to the network layer: the application layer is awfully far removed >from that... > > > > > >> Do you have suggestions on what would help? > > > > So, for core links, my suggestion is to use WRED and drop/set ECN at a > > certain queue depth, for instance 20-30 ms queue depth. Yup, altho just RED would be enough - maybe you mean that. >For access links, > > I'd like to see "fair queuing" (RFC970) enabled on a lot more ADSL/cable > > modems/Wifi routers, and also in hosts. FQ crudely carves up each customer's usage into equal bit-rates. That's better than nothing, but it's very over-constraining. Quoting again from new text in concepts-uses: " Since then capacity has been shared by a mix of traffic management approaches, partly network-based (weighted round-robin scheduling, weighted fair queuing, etc) and partly host-based (TCP). However, in recent years, network operators became concerned that a relatively small number of end-machines were consuming a disproportionately high share of network resources. This is actually because both TCP and all the traditional network-based approaches only share out a bottleneck at each instant. They fail to take account of how much of the time a consumer is keeping the link busy, which is the main factor that determines everyone else's bit-rate. " > > > > RFC1254 also lists different ways of handling this. Generally, I'd say not > > much of this is actually in use on the Internet today, 25+ years later :P > > I run fair-queue on my access link at home, it works great. Have you tried running uTP and Web at the same time through your FQ? FQ forces them to have equal bit-rate, even tho uTP is trying to allow the Web flows to temporarily take more of the capacity. Also if you put multiple variable bit-rate videos through FQ, it forces them all to get constant bit-rate service. Through a given backhaul link, relative to CBR, a good VBR codec can get more than twice as many videos through. If you turn on FQ, it removes the ability to multiplex all the peaks and troughs, and you can only get half the videos through, as if they were CBR again. See "Equitable quality video streaming over DSL," via > These seem reasonable, but not for ConEx to say... > > >> Ah, yes. Buffer tuning is fairly well understood by ISPs, but the > >> distribution-of-information channels don't work well. :^( If you > >> think ConEx could help, please say how! > > > > Er, considering basically NONE of the typical CPEs in use today does > > anything other than FIFO with a lot of buffers, I'd say if the ISP > > understands bufferbloat, they haven't communicated this to the purchasing > > department who controls CPE purchases, because if they did, the typical > > ADSL router would do better things than FIFO for upstream buffer > > management. Not so. Many home gateways have fairly complex queuing arrangments in the upstream with what is essentially simple DPI to classify flows into the different queues. Admittedly, many also have rubbish implementations and bugs, but we tested many of them and there are a few good ones. I'm not saying DPI is a good way to go. I'm just saying what's out there. > As I said, distribution-of-information channels don't work well. :^( > > > So I would like to have ConEx describe how buffering should be implemented > > in all devices who might experience congestion on the outgoing interface > > (hosts and routers, most likely different advice, ConEx perhaps should > > define different classes of devices that should do different things), this > > should be very good guidance going forward. > > Hmm... I don't see where that fits in our current documents. Perhaps >you'd like to try writing an Internet Draft? Altho this isn't the bailiwick of ConEx, this is the goal of a different draft that a bunch of us have promised to write, but just not got round to it (yet). It's under the ICCRG (IRTF). However, it looks like you & I have some disagreements to discuss before we would be able to write anything approaching consensus. Bob >-- >John Leslie >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Tue Jul 26 05:42: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 E003F21F8C68 for ; Tue, 26 Jul 2011 05:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Dg2gVpfqYi7U for ; Tue, 26 Jul 2011 05:42:26 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CE89121F8C03 for ; Tue, 26 Jul 2011 05:42:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 06F4433C25; Tue, 26 Jul 2011 08:42:25 -0400 (EDT) Date: Tue, 26 Jul 2011 08:42:25 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110726124224.GL57285@verdi> References: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> <201107201707.p6KH7LPR004722@bagheera.jungle.bt.co.uk> <371A15DE-0BCF-45D2-88A6-38D2D2B9A0FD@cdt.org> <201107260239.p6Q2dSqf004477@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107260239.p6Q2dSqf004477@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] "traffic management" 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: Tue, 26 Jul 2011 12:42:27 -0000 Bob Briscoe wrote: > At 19:23 22/07/2011, Alissa Cooper wrote: >> >> I think if John's suggestion in this thread about the text in 3.1 is >> followed, that would help to clear up the endpoint-versus-network >> distinction. > > I assume you mean this: > > At 19:13 18/07/2011, John Leslie wrote: >>>" Since then capacity has been shared by a mix of traffic management >>>" approaches, partly network-based (weighted round-robin scheduling, >>>" weighted fair queuing, etc) and partly host-based (TCP). >>> >>> This looks like a wordsmithing oversight: I think Bob meant "mix >>> of congestion management and traffic management approches". > > Well, if we define traffic management as the superset of ways that > traffic is managed, including (rather than excluding) congestion > management, then the original is OK, and it wouldn't make sense to > say "a mix of congestion management and traffic management", just as > it wouldn't make sense to say "a mix of oranges and fruit". Clearly, if we include the phrase "traffic management" at all, we are going to have to include a definition of it. Bob's definition is just too far from what some others think traffic management is. FWIW, I consider "traffic management" to be something operators do in order to share capacity between competing customers in a manner which won't drive away customers; while I consider "congestion management" to be something end-systems do to be good citizens and avoid over-stressing the network. I do not agree with Bob that including all congestion management as a subset of traffic management is a useful way to think of the issues involved. >> There are a number of places in the document where I do think it is >> implied that traffic management is a network operator function >> (e.g., second-to-last para on page 4, first use case in 5.4), so the >> 3.1 clarification would be consistent with those. > > Neither case implies traffic management is *only* something operators > do. Again, if traffic management implies nothing about who is doing > the traffic management, there will be places where we talk about > operators doing it, but that doesn't imply we're saying no-one else > can. Similarly, if I say 40% of women eat an orange per day, I'm not > saying men don't eat oranges. It _is_ reasonable to imagine that network operators in some imagined world might take actions intended to "manage" "congestion", as opposed to managing "traffic". IMHO, this isn't where we should be aiming: we have traditionally assigned "congestion management" to a higher layer than "traffic management". Nonetheless, in the same sense that network operators now do Deep-Packet-Inspection, it is arguably reasonable for them to take more aggressive actions against traffic known to contribute to congestion -- and I would agree that such actions still deserve to be called "traffic management". Where I think Bob and I disagree is in considering such actions to _be_ "congestion management". >> A definition entry, if it made clear that the term applies to >> managing traffic for numerous purposes other than managing >> congestion, could be helpful. That might serve to counter the >> implication of phrases like this one in 5.1, which could be >> understood to mean that the goal of traffic management is only >> performance-driven: "In order to ensure all customers get decent >> performance from the network, they subject the "heaviest" customers >> to some form of traffic management." > > I'm happy to add a definition for traffic management, but as I said, > its value won't be in the definition (managing traffic) but in riders > about what it's not: it's not only performance-driven and it's often > but not necessarily operator driven. We're just going to have to keep pressure on Bob to refrain from always starting definitions with "what it's not". Thus, I'll offer some definitions (not expecting them to be acceptable, but trying to guide us into better weeds to wander in): " " Traffic Management -- actions taken by Network Operators to " manage Layer-3 traffic in order to ensure all customers get " access to infrastructure of limited capacity. " " Congestion Management -- actions taken automatically by programs " and operating systems at higher Layers in order to relieve " congestion known to exist somewhere in the path through the " networks used. -- John Leslie From richard_woundy@cable.comcast.com Tue Jul 26 06:42: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 2BA4521F8BA6 for ; Tue, 26 Jul 2011 06:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.902 X-Spam-Level: X-Spam-Status: No, score=-103.902 tagged_above=-999 required=5 tests=[AWL=-2.167, 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 Sx1djp9mJvCY for ; Tue, 26 Jul 2011 06:42:33 -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 58A1D21F8B8D for ; Tue, 26 Jul 2011 06:42:33 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46171791; Tue, 26 Jul 2011 07:47:00 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Tue, 26 Jul 2011 09:42:16 -0400 From: "Woundy, Richard" To: John Leslie , Bob Briscoe Thread-Topic: [conex] "traffic management" in draft-ietf-conex-concepts-uses Thread-Index: AQHMS5F+HY6FP5d8vUmjOObjf6hZ9pT+m1XA Date: Tue, 26 Jul 2011 13:42:15 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135DA868@PACDCEXMB05.cable.comcast.com> References: <78296019-B269-445E-8601-6E34DBDACD72@cdt.org> <201107201707.p6KH7LPR004722@bagheera.jungle.bt.co.uk> <371A15DE-0BCF-45D2-88A6-38D2D2B9A0FD@cdt.org> <201107260239.p6Q2dSqf004477@bagheera.jungle.bt.co.uk> <20110726124224.GL57285@verdi> In-Reply-To: <20110726124224.GL57285@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] "traffic management" 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: Tue, 26 Jul 2011 13:42:34 -0000 > Clearly, if we include the phrase "traffic management" at all, we are goi= ng to have to include a definition of it. Bob's definition is just too far = from what some others think traffic management is. > FWIW, I consider "traffic management" to be something operators do in order to share capacity between competing customers in a manner which= won't drive away customers; while I consider "congestion management" to be= something end-systems do to be good citizens and avoid over-stressing the = network. Just as a counter-example, note the title of RFC 6057: "Comcast's Protocol-= Agnostic Congestion Management System", which is in alignment with Bob's de= finition. :) I agree that we need to have a common understanding of the terms we use in = Conex. -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of J= ohn Leslie Sent: Tuesday, July 26, 2011 8:42 AM To: Bob Briscoe Cc: conex@ietf.org Subject: Re: [conex] "traffic management" in draft-ietf-conex-concepts-uses Bob Briscoe wrote: > At 19:23 22/07/2011, Alissa Cooper wrote: >> >> I think if John's suggestion in this thread about the text in 3.1 is=20 >> followed, that would help to clear up the endpoint-versus-network=20 >> distinction. >=20 > I assume you mean this: >=20 > At 19:13 18/07/2011, John Leslie wrote: >>>" Since then capacity has been shared by a mix of traffic management >>>" approaches, partly network-based (weighted round-robin scheduling, >>>" weighted fair queuing, etc) and partly host-based (TCP). >>> >>> This looks like a wordsmithing oversight: I think Bob meant "mix >>> of congestion management and traffic management approches". >=20 > Well, if we define traffic management as the superset of ways that=20 > traffic is managed, including (rather than excluding) congestion=20 > management, then the original is OK, and it wouldn't make sense to=20 > say "a mix of congestion management and traffic management", just as=20 > it wouldn't make sense to say "a mix of oranges and fruit". Clearly, if we include the phrase "traffic management" at all, we are going to have to include a definition of it. Bob's definition is just too far from what some others think traffic management is. FWIW, I consider "traffic management" to be something operators do in order to share capacity between competing customers in a manner which won't drive away customers; while I consider "congestion management" to be something end-systems do to be good citizens and avoid over-stressing the network. I do not agree with Bob that including all congestion management as a subset of traffic management is a useful way to think of the issues involved. >> There are a number of places in the document where I do think it is=20 >> implied that traffic management is a network operator function=20 >> (e.g., second-to-last para on page 4, first use case in 5.4), so the=20 >> 3.1 clarification would be consistent with those. >=20 > Neither case implies traffic management is *only* something operators=20 > do. Again, if traffic management implies nothing about who is doing=20 > the traffic management, there will be places where we talk about=20 > operators doing it, but that doesn't imply we're saying no-one else=20 > can. Similarly, if I say 40% of women eat an orange per day, I'm not=20 > saying men don't eat oranges. It _is_ reasonable to imagine that network operators in some imagined world might take actions intended to "manage" "congestion", as opposed to managing "traffic". IMHO, this isn't where we should be aiming: we have traditionally assigned "congestion management" to a higher layer than "traffic management". Nonetheless, in the same sense that network operators now do Deep-Packet-Inspection, it is arguably reasonable for them to take more aggressive actions against traffic known to contribute to congestion -- and I would agree that such actions still deserve to be called "traffic management". Where I think Bob and I disagree is in considering such actions to _be_ "congestion management". >> A definition entry, if it made clear that the term applies to=20 >> managing traffic for numerous purposes other than managing=20 >> congestion, could be helpful. That might serve to counter the=20 >> implication of phrases like this one in 5.1, which could be=20 >> understood to mean that the goal of traffic management is only=20 >> performance-driven: "In order to ensure all customers get decent=20 >> performance from the network, they subject the "heaviest" customers=20 >> to some form of traffic management." >=20 > I'm happy to add a definition for traffic management, but as I said,=20 > its value won't be in the definition (managing traffic) but in riders=20 > about what it's not: it's not only performance-driven and it's often=20 > but not necessarily operator driven. We're just going to have to keep pressure on Bob to refrain from always starting definitions with "what it's not". Thus, I'll offer some definitions (not expecting them to be acceptable, but trying to guide us into better weeds to wander in): "=20 " Traffic Management -- actions taken by Network Operators to " manage Layer-3 traffic in order to ensure all customers get " access to infrastructure of limited capacity. "=20 " Congestion Management -- actions taken automatically by programs " and operating systems at higher Layers in order to relieve " congestion known to exist somewhere in the path through the " networks used. -- John Leslie _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Wed Jul 27 07:55: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 90A1B5E8016 for ; Wed, 27 Jul 2011 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 9XMB-9FLqrSa for ; Wed, 27 Jul 2011 07:55:20 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 89F525E800C for ; Wed, 27 Jul 2011 07:55:17 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 15:55:16 +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); Wed, 27 Jul 2011 15:55:15 +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 1311778514552; Wed, 27 Jul 2011 15:55:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.65.127]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6REtBIA013605; Wed, 27 Jul 2011 15:55:12 +0100 Message-Id: <201107271455.p6REtBIA013605@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jul 2011 10:51:39 -0400 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> 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: 27 Jul 2011 14:55:15.0820 (UTC) FILETIME=[31D6AAC0:01CC4C6D] Cc: ConEx IETF list Subject: [conex] conex-concepts-uses proposed changes to ToC: use-cases X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:55:21 -0000 Alissa, I said I was going to respond to each of your suggested changes in chunks, moving to the next as discussion closes on the previous... Inline... At 08:58 18/07/2011, Alissa Cooper wrote: >Hi Bob, > >I am finding the organization of the document somewhat confusing. >With the introduction of new text in early sections, it has also >become a bit repetitive in parts. I'll throw out an alternative >organization below with some explanation afterward: > >1. Introduction >2. Concepts >3. Definitions >4. Core Use Case: Informing Congestion Management > 4.1 History > 4.2 Existing Approaches > 4.3 Drawbacks of Existing Approaches Including non-congestion management approaches (DPI etc) under the main section heading "Congestion Management" seems to contradict or at least confuse the message that these techniques should not actually be classified as congestion management. > 4.4 Use Case Description This heading needs to be where the term "Informing Congestion Management" appears. But that doesn't make it clear that ConEx is informing the Operator - in fact it could be skim-read as host congestion management. The problem is that ConEx redefines who does Congestion Management (operator not just host) and who does Traffic Management (host - LEDBAT/QoS - not just network). So preconceptions on who does these functions get in the way. >5. Other Use Cases > 5.1 Creating Incentives for Scavenger Transports > 5.2 Supporting Intra-Class Quality of Service > 5.3 Preventing Congestion Collapse > 5.4 Informing Inter-Operator Contracts > 5.5 Informing Capacity Provisioning >6. Deployment Arrangements (sub-outline structure as is for now) >7. Commercial Secrecy as a Potential Deployment Barrier >8. Non-Goals >9. Security Considerations >10. IANA Considerations >11. Acknowledgments >12. Contributors > >4. Core Use Case: Informing Congestion Management -- As of now the >document sort of wavers between emphasizing traffic management (what >I'm calling congestion management) as the key motivating use case >and mixing in some of the other motivating use cases. I think your structure misses the point (made on the list, not in the current draft yet, other than in the section headings) that LEDBAT & QoS have traffic management as a pre-requisite. ConEx is about co-operative traffic management. Also see later discussion. >A clearer separation would help, I think. I more strongly disagree about this point than anything else. What we have been trying to do all along is to ensure a single message comes out of this doc: ConEx does good traffic management and gets the hosts and network to co-operate in same. That's why LEDBAT & QoS were main use-cases with traffic management, and the Others were "Other". A more nitty point was that we had bulletted the "Others" rather than given them separate section headings, because we wanted just a few sentences on each, because we didn't want to allow them to push the main message out of mind. >I also found the narrative of current sections 3 and 4 (Traffic >Management and Exposing Congestion) to be somewhat disjoint and >repetitive, thus my suggestions for streamlining 4.1-4.4 above. 4.1 >maps to the current intro to section 3; 4.2 maps to the first part >of the current 3.1; 4.3 maps to the second part of the current The existing approaches have been an evolution: Each time a problem has arisen with one approach another has been added. That's the story in the Intro and it's given in more detail here. Altho it seems that splitting existing approaches and problems with existing approaches would make sense, it wouldn't flow given this patch-problem-patch-problem-patch-problem history. >3.1 plus the ECN discussion currently in 4.1; and 4.4 maps to the >current 5.1. I think parts of the intro to the current section 4 are >now redundant and other parts can be fit in to the subsections above >as appropriate (e.g., the LEDBAT discussion could go in the suggested 5.1). I can't parse the section numbers here - I am beginning to think there are some typos. The current 5.1 is "Inform the Operator's Traffic Management" * How does "3.1 Existing Approaches to Traffic Management" map to that? * How does ECN discussion map to that? * I can only see how 4.4 "Use Case Description" maps to that >5. Other Use Cases -- This is just the list from the current draft, >although phrased in the active voice. I find the distinction between >consequences and use cases to be of little use; in every case, ConEx >just exposes information and it is up to the operator to act on it, >so in some sense every use case is a consequence. For the "Informing >Traffic Management" case, for example, I don't think the expectation >is that operators will merely be glad to have more information, but >they will actually act on it (perhaps by using an ingress policer as >described). The same can be said for incentivizing scavenger >transports: the operator has to take affirmative steps using the >ConEx information to create the incentives. I don't see the >difference between the two. The point Phil made, which I liked, was that a use-case shouldn't be described as if it is a separate use case, if it can only exist after another use-case has happened. Things consumers (or their software-providers) do (LEDBAT, QoS) in response to ConEx traffic management fall into this category. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Jul 27 08:07: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 1AB0B11E8084 for ; Wed, 27 Jul 2011 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 h5OhAMayADO9 for ; Wed, 27 Jul 2011 08:07:37 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4858C21F8BA8 for ; Wed, 27 Jul 2011 08:07:36 -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); Wed, 27 Jul 2011 16:07:35 +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); Wed, 27 Jul 2011 16:07:31 +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 1311779250623; Wed, 27 Jul 2011 16:07:30 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.65.127]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6RF7RXh013710; Wed, 27 Jul 2011 16:07:28 +0100 Message-Id: <201107271507.p6RF7RXh013710@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jul 2011 11:07:24 -0400 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> References: <201107061057.p66Av11f020498@bagheera.jungle.bt.co.uk> <201A89A2-1F9F-4E91-B41D-9102E0C02753@cdt.org> 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: 27 Jul 2011 15:07:31.0770 (UTC) FILETIME=[E87FB9A0:01CC4C6E] Cc: ConEx IETF list Subject: [conex] conex-concepts-uses proposed changes to ToC: Potential Issues 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, 27 Jul 2011 15:07:38 -0000 Alissa, The final posting in this series, on your last point, inline... At 08:58 18/07/2011, Alissa Cooper wrote: >Hi Bob, > >I am finding the organization of the document somewhat confusing. >With the introduction of new text in early sections, it has also >become a bit repetitive in parts. I'll throw out an alternative >organization below with some explanation afterward: > >1. Introduction >2. Concepts >3. Definitions >4. Core Use Case: Informing Congestion Management > 4.1 History > 4.2 Existing Approaches > 4.3 Drawbacks of Existing Approaches > 4.4 Use Case Description >5. Other Use Cases > 5.1 Creating Incentives for Scavenger Transports > 5.2 Supporting Intra-Class Quality of Service > 5.3 Preventing Congestion Collapse > 5.4 Informing Inter-Operator Contracts > 5.5 Informing Capacity Provisioning >6. Deployment Arrangements (sub-outline structure as is for now) >7. Commercial Secrecy as a Potential Deployment Barrier >8. Non-Goals >9. Security Considerations >10. IANA Considerations >11. Acknowledgments >12. Contributors > >7. Commercial Secrecy as a Potential Deployment Barrier and 8. >Non-Goals -- From the text it seems like dealing with >self-congestion is a non-goal, so it probably can be fit in the >non-goals section. And I agree with earlier reviewers that putting >non-goals up front is a non-starter. If the section is listed in the >ToC and previewed at the end of the introduction, people who are >confused will be able to find it (as opposed to possibly confusing >many people by putting it up front before the actual goals have >really been discussed). I don't think anyone is saying that distinguishing self-congestion from shared congestion is a non-goal. But many people are saying ConEx (or re-ECN?) can't distinguish these, and that it should be able to. That means self-congestion is a "potential issue". Also, I've proposed a way the two can be distinguished in some important cases (see recent mail to Mikael), but I know it's not possible in some cases. Therefore this is a non-issue sometimes, and a potential issue others. That's why we created a Potential Issues section and made Commercial Secrecy a sub-section, and self-congestion another subsection. Whatever, we want to move text about self-congestion from the introduction, where it was in -01. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 28 04:43: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 C860521F8853 for ; Thu, 28 Jul 2011 04:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 DImNzXasQg17 for ; Thu, 28 Jul 2011 04:43:08 -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 ABCA421F87E2 for ; Thu, 28 Jul 2011 04:43:07 -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 280D3633B1 for ; Thu, 28 Jul 2011 13:43:05 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 98F3259A8A for ; Thu, 28 Jul 2011 13:43:02 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Thu, 28 Jul 2011 13:43:00 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201107281343.00909.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] Fwd: [ITG-FG524-Announce] Deadline Extension: Workshop on "Capacity Sharing" 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, 28 Jul 2011 11:43:08 -0000 Hi, this is a quite short notice for a Call for Contributions as the Deadline i= s=20 Monday. But this might still be interesting for you (and we only require an= =20 abstract). I'll send a Call for Participation and the program in about two= =20 weeks... Mirja=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Submission Deadline extended to August 1, 2011 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Call for Contributions ---------------------- NEC Laboratories Europe and the Institute of Communication Networks and Computer Engineering (IKR) of the University of Stuttgart invite you to a one-day workshop on the topic ---------------- Capacity Sharing ---------------- With the increasing amount of IP traffic in fixed and mobile access networks, the question how to share the available resources in a fair, efficient and demand-oriented way becomes more and more prevalent. With the variety of services one can find in today's Internet, the requirements in rate, data volume and latency differ strongly. To maximize resource utilization and, at the same time, provide satisfying performance to all users, application layer knowledge is needed. As different resource allocation and adaptation mechanisms already exist in MAC, transport and application layer, an integral consideration of the problem space is required. In wireless networks, the problem is particularly relevant due to the inherently limited resources, which render a simple "throwing bandwidth at the problem" solution impossible. Because large over-provisioning factors are economically unfeasible, similar questions on capacity sharing also arise in fixed access networks, such as high bandwidth passive optical networks or cable networks. The objective of this workshop is to bring together stakeholders of mobile and fixed access networks, the classic Internet world and of the application and transport community. We solicit presentations on the state-of-the-art, results of ongoing research, open issues, trends and new ideas. We are especially looking forward to (possibly provocative) visionary presentations to foster a lively discussion about how to face the upcoming challenges in the future mobile Internet. Topics of particular interest include, but are not limited to * Application-layer adaption for mobile services * Transport layer solutions and possible interactions with cellular/fixed access networks * Context-aware resource allocation & cross-layer adaptation * QoE and fairness definitions, metrics and evaluation * Data traffic characteristics in fixed and mobile Internet * Economic aspects on capacity sharing and business models * Similarities and differences of capacity sharing in mobile and fixed access networks * Related standardization activities and projects Submission Information ---------------------- Please inform the workshop organizers by email to about title and=20 abstract (max. 1 page) of your planned presentation. The number=20 of slots is limited. Important Dates --------------- Deadline for contributions: August 1, 2011. Registration to the workshop: September 15, 2011. Workshop date: October 13, 2011. Further Information ------------------- =46or further information, please check our website or send a mail to the workshop organizers: http://www.ikr.uni-stuttgart.de/CapacitySharingWS/ CapacitySharingWS@ikr.uni-stuttgart.de Dirk Kutscher (NEC), Mirja K=FChlewind (IKR), Christian Mueller (IKR) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 28 04:43: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 8534D21F8A6F for ; Thu, 28 Jul 2011 04:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 AAxzsWHoXfO0 for ; Thu, 28 Jul 2011 04:43:56 -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 B2AC821F8A64 for ; Thu, 28 Jul 2011 04:43:55 -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 E3392633B1 for ; Thu, 28 Jul 2011 13:43:54 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id DA51A59A8A for ; Thu, 28 Jul 2011 13:43:53 +0200 (CEST) Content-Disposition: inline From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Thu, 28 Jul 2011 13:43:53 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201107281343.53228.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] Deadline Extension: Workshop on "Capacity Sharing" 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, 28 Jul 2011 11:43:56 -0000 Hi, this is a quite short notice for a Call for Contributions as the Deadline i= s=20 Monday. But this might still be interesting for you (and we only require an= =20 abstract). I'll send a Call for Participation and the program in about two= =20 weeks... Mirja=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Submission Deadline extended to August 1, 2011 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Call for Contributions ---------------------- NEC Laboratories Europe and the Institute of Communication Networks and Computer Engineering (IKR) of the University of Stuttgart invite you to a one-day workshop on the topic ---------------- Capacity Sharing ---------------- With the increasing amount of IP traffic in fixed and mobile access networks, the question how to share the available resources in a fair, efficient and demand-oriented way becomes more and more prevalent. With the variety of services one can find in today's Internet, the requirements in rate, data volume and latency differ strongly. To maximize resource utilization and, at the same time, provide satisfying performance to all users, application layer knowledge is needed. As different resource allocation and adaptation mechanisms already exist in MAC, transport and application layer, an integral consideration of the problem space is required. In wireless networks, the problem is particularly relevant due to the inherently limited resources, which render a simple "throwing bandwidth at the problem" solution impossible. Because large over-provisioning factors are economically unfeasible, similar questions on capacity sharing also arise in fixed access networks, such as high bandwidth passive optical networks or cable networks. The objective of this workshop is to bring together stakeholders of mobile and fixed access networks, the classic Internet world and of the application and transport community. We solicit presentations on the state-of-the-art, results of ongoing research, open issues, trends and new ideas. We are especially looking forward to (possibly provocative) visionary presentations to foster a lively discussion about how to face the upcoming challenges in the future mobile Internet. Topics of particular interest include, but are not limited to * Application-layer adaption for mobile services * Transport layer solutions and possible interactions with cellular/fixed access networks * Context-aware resource allocation & cross-layer adaptation * QoE and fairness definitions, metrics and evaluation * Data traffic characteristics in fixed and mobile Internet * Economic aspects on capacity sharing and business models * Similarities and differences of capacity sharing in mobile and fixed access networks * Related standardization activities and projects Submission Information ---------------------- Please inform the workshop organizers by email to about title and=20 abstract (max. 1 page) of your planned presentation. The number=20 of slots is limited. Important Dates --------------- Deadline for contributions: August 1, 2011. Registration to the workshop: September 15, 2011. Workshop date: October 13, 2011. Further Information ------------------- =46or further information, please check our website or send a mail to the workshop organizers: http://www.ikr.uni-stuttgart.de/CapacitySharingWS/ CapacitySharingWS@ikr.uni-stuttgart.de Dirk Kutscher (NEC), Mirja K=FChlewind (IKR), Christian Mueller (IKR) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D------------------------------------------------------ From nanditad@google.com Sat Jul 30 00:06: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 A617A21F8CB1 for ; Sat, 30 Jul 2011 00:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUg7f9TxsUcj for ; Sat, 30 Jul 2011 00:06:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 01E2B21F8C81 for ; Sat, 30 Jul 2011 00:06:37 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p6U76b20019343 for ; Sat, 30 Jul 2011 00:06:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312009597; bh=7chXGAcRdbBKD2ftdQohfuyJs24=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=F8i9PjWUNKMf1DaaQtKy4ObBZvOhY8t7/Ezy8bngsiZt3V94jR+3f457nLMubAe56 OpzCTOa/InnL6TeE3mZlA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to: content-type:x-system-of-record; b=rQjC+af6/GR7bpC7gpDfVsHakh8LSIY9gJhhpeC+JmhJ9RODZJNT2LqKChhF1TQ9f zyN1PvheTWmLQc/nPeMWQ== Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by wpaz24.hot.corp.google.com with ESMTP id p6U76aBq024947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Jul 2011 00:06:36 -0700 Received: by qyk29 with SMTP id 29so209068qyk.19 for ; Sat, 30 Jul 2011 00:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZpNr5St6/6+0lj+/DWTrFMUwziVdJbMDFhsU1GPFZ40=; b=eUhiElVCstwtJc1xehpAlKRcvJ+jq0u4YVgF5zv8ohckroM0Cli50lCpcQW6ze9xSi VYILYQfHd2kYMSF+ZKaw== Received: by 10.229.114.200 with SMTP id f8mr1656616qcq.68.1312009596037; Sat, 30 Jul 2011 00:06:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.200 with SMTP id f8mr1656611qcq.68.1312009595884; Sat, 30 Jul 2011 00:06:35 -0700 (PDT) Received: by 10.229.77.76 with HTTP; Sat, 30 Jul 2011 00:06:35 -0700 (PDT) Date: Sat, 30 Jul 2011 00:06:35 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=00235429d6b8e796a404a94409e8 X-System-Of-Record: true Subject: [conex] Conex IETF-81 meeting minutes 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, 30 Jul 2011 07:06:41 -0000 --00235429d6b8e796a404a94409e8 Content-Type: text/plain; charset=ISO-8859-1 Hi Everyone, The Conex meeting minutes are at the following link: http://www.ietf.org/proceedings/81/minutes/conex.txt Please email me for any corrections/additions. Thanks! to Andrew McGregor for recording the minutes. Nandita --00235429d6b8e796a404a94409e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Everyone,

The Conex meeting minutes are at the following link:=A0http://www.ietf.org/proce= edings/81/minutes/conex.txt
= Please email me for any corrections/additions.<= /span>

Thanks! to Andrew McGrego= r for recording the minutes.

Nandita
 --00235429d6b8e796a404a94409e8--