From john@jlc.net Fri Dec 2 15:20:56 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A717711E807F for ; Fri, 2 Dec 2011 15:20:56 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohVMwjvjvVCb for ; Fri, 2 Dec 2011 15:20:53 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 45ACD1F0C59 for ; Fri, 2 Dec 2011 15:20:51 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2CBBA33C21; Fri, 2 Dec 2011 18:20:51 -0500 (EST) Date: Fri, 2 Dec 2011 18:20:51 -0500 From: John Leslie To: Dirk Kutscher Message-ID: <20111202232051.GH31463@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] byte vs packet counting 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, 02 Dec 2011 23:20:56 -0000 Dirk Kutscher wrote: > [John Leslie wrote:] > >> I sincerely hope Bob isn't saying that an audit function has to >> evaluate _every_ packet which passes it! > > Clearly, it at least has to be able to do that, yes! Clearly, _if_ it has to do that, we're extremely limited on _where_ we can put an auditing function. Auditing is not going to get built into the hardware of 10-gig routers. > Auditing is really a fundamental piece of the basic Conex mechanism, I'd be happy to discuss that. I see no reason to bother auditing if the entire path is known to be free of congestion. Auditing might make sense if you expect traffic you send to encounter congestion later in the path, but only if you have some contractual arrangement calling for it. (Otherwise, you can't know what the effect of ConEx marks may be.) Auditing every packet is plausible near the sender and receiver, but not in the backbone. I don't believe we have agreement among ourselves what a receiver's uplink will do if their auditing shows "abuse" of ConEx marking: so I don't see what auditing at the sender's uplink can do and be confident it's the right thing. I suppose it's possible the experiments we do will enlighten that question, but I'm not confident. :^( > and has nothing to do with policy. Auditing is the basis for accurate > congestion exposure. The Internet works as well as it does precicely _because_ nobody gets too paranoid about how "accurate" packets are -- instead we spend our efforts worrying how well the implementations of our protocols "interoperate". (That keeps us busy enough, IMHO.) > Only if you have that, you can think about implementing policies. As an ISP, I "implement policies" all the time based upon guesswork. The general principle is that a partly-wrong policy implemented at the right time is almost always better than a "right" policy implemented too late. > Having said that, it is certainly implementation-specific how > auditing really works -- there may be tradeoffs between efficiency > and effectiveness -- but for the sake of the discussion here, I'd > say it's best to assume that, yes, auditing evaluates every packet. IMHO, it's _always_ best to assume otherwise. Your life will be easier if you don't depend on assumptions which are likely to be false. We'd do better, when discussing this, to get specific about how auditing might improve the use-cases we're pushing. Unless I misread draft-ietf-conex-concepts-uses, our principle use case is Informing Traffic Management. I have posted before that the most important feature of ConEx marking (IMHO) is informing any node along the way that the sender is knowingly sending packets despite having reason to doubt that congestion has cleared. Auditing does nothing to help here. The abusive thing to do is to _clear_ ConEx marks -- and auditing can't detect that. I haven't yet argued a specific benefit to ECN-marking instead of dropping -- when I do, I'll be arguing for ECN-marking well before packets need to be dropped. I simply don't believe that any amount of auditing will convince providers to trust ConEx marking to mean these packets will never be dropped. Auditing, to tell truth, may or may not prove useful after we have done enough experiments. IMHO, if it proves useful we'll find that it's useful when done statistically, rather than on every packet. -- John Leslie From john@jlc.net Fri Dec 2 16:21: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 884BE11E80C1 for ; Fri, 2 Dec 2011 16:21:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vpq7AIjhUMn for ; Fri, 2 Dec 2011 16:21:51 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0911E80B9 for ; Fri, 2 Dec 2011 16:21:50 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 51E5F33C22; Fri, 2 Dec 2011 19:21:50 -0500 (EST) Date: Fri, 2 Dec 2011 19:21:50 -0500 From: John Leslie To: Matt Mathis Message-ID: <20111203002150.GI31463@verdi> References: <201111171402.pAHE26tB006646@bagheera.jungle.bt.co.uk> <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@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 list Subject: Re: [conex] byte vs packet counting 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, 03 Dec 2011 00:21:52 -0000 Matt Mathis wrote: > > Bob and I prefer to argue in private, because it works better. The IETF way, alas, is to argue in public. We need to learn how to do so without overly harming our ability to work together. > We always assume that the other person is correct, and make every > effort to try to understand what they think and why. This is why we > have often been able to clearly restate each others arguments. A decidedly useful practice. Alas, I seem to have no luck restating Bob's arguments. He reminds me a bit of John Campbell of "Analog" fame, of whom it was frequently said, "if he finds you're agreeing, he changes the subject!" > What typically happens is that we discover some hidden assumption, > and that both of our initial positions are over simplifications and > at some level both are wrong. Congratulations! I'm more than willing to both be wrong. ;^) > When we argue in public, the entire discussion get rat holed about > details that are aren't on the table, either because the rest of us > already have consensus or they just are not important at this stage. Consensus isn't something for "the rest of us" to have. In the IETF, we talk of "rough consensus". That doesn't mean that some of us deserve to be ignored: it means that some of us agree to "be in the rough" and stop arguing an issue. As for "important at this stage", I'm afraid none of us are omniscient enough to know what's important. There is, however, a time when folks are "ready to learn" and a much larger time when they aren't. :^( But IMHO they only deceive themselves when they say "it's not important" instead of "I'm not ready". But I digress... > My take away from the intended discussion with Bob is that > -abstract-mech- is flawed in that it is entirely too casual about > units. I'd be happy to work on what the "units" should be. > The units (primarily bits v bytes v packets of congestion) should > be an explicitly chosen parameter for each span of the model > (congested router to receiver, ACKs carrying the signal back to > the sender, reinserted feedback from the sender to the audit > and policy functions). That sounds difficult... > While I am inclined to agree with Bob that the congestion signal > should be in bytes, (I'm less inclined...) > I am less convinced that it is ok for the ACKs to only carry > segment counts. I am willing to proceed on the basis of his > assumptions, however it is critical that we all understand that > this is a design decision that might be changed in the future if > there is a compelling reason to do so. I understand _that_ Bob believes counting bytes is more correct than counting packets, but I don't understand why he believes it. I see folks responding to his repeated claims with, "But it's not the case for this common situation;" and there the thread dies. Elsewhere, I read of concerns that "small packets shouldn't be penalized for being small," but I don't know if that's Bob's argument. Whether or not it is, I find it unconvincing. If small packets were _actually_ being significantly punished for being small, the sender would find a way to enlarge them. I simply don't see that in the wild. And that argument seems to really be, "Look how nice I'm being by sending smaller packets! Why don't folks reward me more?" (I can think of a half-dozen reasons, which I won't list.) In practice, the folks who do send lots of small packets want to see less jitter in RTT. But it's the large packets which usually cause the jitter. Alas, the medium is shared... > The abstract mech doc needs to state that proposed signal mappings > for a given tentative encoding must be explicit about units. That sounds like an improvement... > It is also important to note that for legacy interoperability > using a sender only implementation, we can not assert different > algorithms than are present in current network devices and ECN > enabled receivers. I agree these, in practice, are unknowable. :^( > My example earlier in the thread illustrates a rather extreme > pathological case where bytes v segments might change sender > behavior. In the common case and as a natural approximation, > the sender will probably assume that the data in not lumpy, and > that reflecting the correct number packets is good enough. It strikes me as seriously sub-optimal to say, "It's reasonable to assume X" and at the same time, "It's more correct to punish anyone who assumes X". I frankly don't see why abstract-mech needs to say either of these. We should perhaps state that experiments may include scenarios where some nodes may punish X while other nodes may punish Y; but I'm very uncomfortable with suggesting that either of those punishments is "correct". > Clearly when all of the packets in a given connection have uniform > sizes, it doesn't matter to any component, except the policy devices. I think we have agreement there... > The places proper treatment of lumpy data might matter are the > policy and audit devices, which will be the last part of ConEx to > have fully bound specifications. Agreed. > Some of their details are even explicitly out of our scope, > although we do have to demonstrate the existence of algorithms that > provide useful signals. Algorithms, plural, yes. > As I reflect on the broader debate, it is clear to me that we > really need to understand choosing units of congestion as an > engineering compromise. Perhaps even an engineering compromise where different senders and receivers make different trade-offs? > Like all such compromises, it has to balance the costs of > difficulty of implementation vs opportunity cost of reduced > precision. Agreed. > Furthermore, extended debate without hard data is pointless. > It just doesn't matter at this stage. We can accept Bob's assumption > for the time being, note that it is "provisional" and revisit it > later, if or when we encounter a problem that would be better > solved with different assumptions. Remember the Tao of Internet: "We reject kings, presidents, and voting..." I don't remember electing Bob as President; nor do I see good reason to accept him as King. What other reason is there to accept Bob's assumption when we have so much reason te believe it is incomplete or worse? > John, can we arrange a phone call some time? (Matt and I have talked at some length on the phone. I like to believe I have a better understanding of research in this field because of this. I just don't read the research the same way Bob does...) -- John Leslie From john@jlc.net Mon Dec 5 03:33: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 C8F0321F8B77 for ; Mon, 5 Dec 2011 03:33:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2H9G1GCZ4Wg for ; Mon, 5 Dec 2011 03:33:58 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF1721F8B73 for ; Mon, 5 Dec 2011 03:33:58 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id DEBFC33C21; Mon, 5 Dec 2011 06:33:56 -0500 (EST) Date: Mon, 5 Dec 2011 06:33:56 -0500 From: John Leslie To: marcelo bagnulo braun Message-ID: <20111205113356.GJ31463@verdi> References: <4EC468D5.5040009@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC468D5.5040009@it.uc3m.es> User-Agent: Mutt/1.4.1i Cc: 'ConEx IETF list' Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-03.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, 05 Dec 2011 11:33:59 -0000 marcelo bagnulo braun wrote: > > Please review the document and send comments before the 5th december. The overall effect of this document is that of an impenetrable academic paper. :^( I'd prefer something more approachable. (Alas, I have been busy the past few weeks, and didn't set aside enough time to review it: thus I've missed the deadline by local time, though not necessarily by "any-time-zone" rules. ;) This I-D contains a lot of good material. The organization is a bit confusing, but IMHO would be good if we were more selective in what we include. For one example, proxies are introduced but not explained in sufficient detail. They do not strike me as in any way necessary to the ConEx mechanism -- merely a potential tool to speed deployment... I'd go a lot easier on the part about competing Congesiton-Control algorithms. Our point is that there are many of them and we expect more, with ConEx merely signaling the detected loss and/or ECN marks. Specifically, I'd replace the third bullet in section 1 with something like, "Some alternate CC algorithms use delay as an input. ConEx does not treat delay as a measure of congestion, and is concerned only with ECN marking and packet loss." I'd omit the paragraph before Figure 1: it introduces ideas better introduced elsewhere. 1.1 Terminology "Congestion level" is used but not defined. 2 Requirements for the ConEx Signal In 2.a I strongly recommend removing mention of IPv4 -- it's outside our charter. In 2.c "auditing" is used in a somewhat non-intuitive manner, to mean a function which both derives information and acts upon it to change the flow. I'd much rather introduce "auditing" as gathering information, not policing. Thus I recommend against "must have a capability of providing sufficient disincentives". As we gain experience with ConEx, I expect disincentives will be found, but it's premature to say here what they may turn out to be. In 2.d I fully agree that ConEx should include building "credit" against congestion expected before the feedback time (likely to be several RTTs). However (IMHO) it's not good to tie this to the auditing function. We've already seen on-list some substantial confusion from this. We have folks gravitating towards setting the "credit" bit on every packet "just in case". This is not useful: a ConEx signal which is always present is no more useful than a ConEx signal which is never present. My strong opinion is that all nodes along the path should be able to determine a "congestion-expected" metric which reasonably tracks the congestion impairment for the flow in question. It's premature (IMHO) to say just how to do this, but I think it would be best to treat the "credit" signal as an "expectation" at the start (or resumption) of a flow, which suggests that different CC algorithms may choose to set it differently. Such details shouldn't be nailed down too early. A general comment here: in a number of places in this I-D, the reader trying to imagine how to implement ConEx will boggle on how to implement the "auditing function". It seems to require per-flow state at points along the path where this is wildly impractical. I do not believe ConEx needs such a draconian function that seems to be requiring high estimates for "credit". It's not that I object to such a function _existing_ -- rather that this is just _one_ way to use ConEx signals. Even if it is in fact the best way, requiring it at the outset of Experimental phase scares me. There is perhaps an unstated assumption that we can have policing near the sender which will satisfy all nodes along the path about the accuracy of congestion prediction. To an operator this is laughable. My honest suggestion is to separate out any details of an auditing function which includes policing into a separate document which we can revise as we gain experience. Abstract-mech will be stranger if it limits itself to how to signal the interesting metrics, without tryinng to specify how to make them trustworthy. In any case, I recommend cutting back 2.d to something like, "The ConEx signal SHOULD be timely. There will be a minimum delay of one RTT, and often it will be longer. In order for nodes along the path to ignore this delay, ConEx signals SHOULD include a "credit" signal to cover congestion (not yet measured) during this delay." The information about ECN congestion being best audited near the receiver, etc., is important, but deserves its own section later in the document. Personally, I'd leave out all mention of how to infer loss at an auditing point. It's not IMHO a _ConEx_ mechanism -- it's a research topic during experiments. While Matt and Bob may be right that this is the best way to do it, the world is more complicated than we _can_ imagine and I expect our readers to imagine lots of alternatives. The statement about signaling loss separately from ECN is critically important IMHO, and very much deserves its own section. Though we may not want to go into detail about differing AQM algorithms and parameters, these are an important part of what should be tried during experiments, and I'd like to hint more at that. (To digress, DCTCP for example uses AQM parameters to signal queue depth much more aggressively than the ECN standard implies, and this turns out to be very useful in the limited environment where DCTCP is used. There is almost certainly an opportunity to develop somewhat similar AQM signaling in the big-I Internet, where ECN marking could be common at nodes where packet loss is quite rare. We cannot make such changes to ECN in this WG as currently chartered; but I'd like to leave room to develop experiments in that direction.) 3. Encoding Congestion Exposure I'd omit entirely the "Naive Encoding". For academic papers, this would be helpful, but here we need to get to the point. We're going to end up with at least 4 independent bits: it can't help implementors that we dwell on alternatives. (So 3.1 shouldn't be a separate section.) 3.2 ECN Based Encoding Talking of sharing ECN codepoints only confuses the reader. It can't be understood without going into a lot of re-ECN details, and that's not the path we will take. I'd omit 3.2. The ECN changes section mention of a "different state machine" is particularly confusing, but I don't believe it is needed for ConEx. (If it is, it needs a lot more explanation.) Section 3.3 feels like the right introduction. Section 3.3.1 should match the actual naming of the independent bits, if possible. If we maintain "abstract-mech" as an I-D, we can change these if needed without needing to revisit the whole document. Section 3.3.2 should be deleted -- we're not going to recommend this. 4. Congestion Exposure Components I dissent on assigning a policing role to the "auditing function". "Auditing" and "Policing" were kept separate in use-cases while I was on the editing team, and I strongly recommend keeping the separate still. Eventually, they may belong in the same box, but auditing with no policing will remain a useful function. I further suggest that mandating the two be combined does not belong in an "Abstract Mechanism" document. Nor is the policing function made any easier to understand by forcing this combination. I'd prefer that any details of auditing and/or policing be in a separate document, and abstract-mech merely refer to it as an optional addition to the basic mechanism. Arguments that ConEx is useless without policing don't convince me. If true, ConEx would be just as useless without trustworthy policing, and to an ISP any policing done by a competitor is by definition untrustworthy. Most of the rest of Section 4 is pretty good. I'm a bit nervous about seeming to require ECN-feedback changes, but I don't think the text intends to actually require them. I'd be happier if all of Section 4.4 (including 4.4.1 and 4.4.2) disappeared into a separate document. 4.5 Policy Devices This is rather good, but I wonder how well it represents an actual consensus of this WG -- I'd feel more comfortable with a record of discussion in the archives of this mailing-list. While I don't disagree with 4.5.2, I'm uncertain how many of us want to try this. In 4.5.3, I'm actively uncomfortable with the term "Congestion Policer". To me, this is describing a particular case of a Policy Device, and is by no means the only "policing" function a Policy Device might do. Perhaps we could find another term along the lines of "Packet Sorter". The implication needed is that at any organizational boundary it's reasonable to limit the "congestion-expected" that you allow into your network. (Whether you limit by bytes, packet, or some combination is a local decision hopefully covered by contractual agreements.) When presented with traffic which exceeds such limits, reducing the scheduling priority or selectively dropping packets is reasonable (though of course not _required_ by ConEx protocol). (The use of "Not-ConEx-Marked" may or may not be right in this paragraph: I have not tried to work that out. IMHO any such details are local, and other sorting algorithms seem allowable.) 5. Support for Incremental Deployment There's a lot of good stuff here... perhaps too much. I would, for example, omit any mention of proxies. I could go into a lot more detail, but I think this email is long enough. 7. Security Considerations This section needs actual discussion of some threats. (The less we promise, the less threats we need to discuss!) 8. Conclusions This isn't needed as a section in an Internet-Draft. 11.2. Informative References I appreciate the joke, but do we really want to reference RFC3514? -- John Leslie From tm444@hermes.cam.ac.uk Mon Dec 5 09:55:01 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC421F8C1F for ; Mon, 5 Dec 2011 09:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0u4W84zOsYS for ; Mon, 5 Dec 2011 09:55:00 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id AD32D21F8C43 for ; Mon, 5 Dec 2011 09:54:59 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:60718) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1RXcki-0006v5-Xp (Exim 4.72) for conex@ietf.org (return-path ); Mon, 05 Dec 2011 17:54:56 +0000 From: Toby Moncaster Content-Type: multipart/alternative; boundary="Apple-Mail=_E3AB3FA2-5AE7-4062-8807-674D5416E98E" Date: Mon, 5 Dec 2011 17:55:00 +0000 References: To: conex@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Sender: "T. Moncaster" Subject: [conex] Fwd: byte vs packet counting 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, 05 Dec 2011 17:55:01 -0000 --Apple-Mail=_E3AB3FA2-5AE7-4062-8807-674D5416E98E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Not sure if this email ever hit the mailing list=85 Begin forwarded message: > From: "T. Moncaster" > Subject: Re: [conex] byte vs packet counting > Date: 3 December 2011 10:10:52 GMT > To: John Leslie > Cc: Dirk Kutscher , ConEx IETF list = >=20 > I have been purposely not contributing to this thread over the past = few weeks as I wasn't sure that more voices in the argument would = actually help things. However I feel things are now at a point where I = can contribute something (hopefully) useful. >=20 > On Dec 2 2011, John Leslie wrote: >=20 >> Dirk Kutscher wrote: >>> [John Leslie wrote:] >>>> I sincerely hope Bob isn't saying that an audit function has to >>>> evaluate _every_ packet which passes it! >>> Clearly, it at least has to be able to do that, yes! >>=20 >> Clearly, _if_ it has to do that, we're extremely limited on _where_ >> we can put an auditing function. Auditing is not going to get built >> into the hardware of 10-gig routers. >>=20 >>> Auditing is really a fundamental piece of the basic Conex mechanism, >>=20 >> I'd be happy to discuss that. I see no reason to bother auditing >> if the entire path is known to be free of congestion. Auditing might >> make sense if you expect traffic you send to encounter congestion >> later in the path, but only if you have some contractual arrangement >> calling for it. (Otherwise, you can't know what the effect of >> ConEx marks may be.) >=20 > I think there is a subtle difference between stating that auditing is = a fundamental part of ConEx and saying that auditing can never be turned = off. I would definitely agree that auditing is required in any network = where there are potential trust issues and where you can't guarantee the = whole-path network conditions. But I do think there are cases where it = could be turned off (for instance in private corporate networks using = conex as a means to control their monthly network bills). >=20 >>=20 >> Auditing every packet is plausible near the sender and receiver, >> but not in the backbone. I don't believe we have agreement among >> ourselves what a receiver's uplink will do if their auditing shows >> "abuse" of ConEx marking: so I don't see what auditing at the >> sender's uplink can do and be confident it's the right thing. >=20 > I agree, it seems hard to see how auditing something when you are = missing half the information is going to be hard. There are possible = arguments along the lines of an ISP might make a decision that all users = of a given access node (B-RAS or whatever) are likely to be experiencing = roughly similar amounts of congestion. So any customer that declares no = congestion is probably not being honest. >=20 >>=20 >> I suppose it's possible the experiments we do will enlighten >> that question, but I'm not confident. :^( >>=20 >>> and has nothing to do with policy. Auditing is the basis for = accurate >>> congestion exposure. >>=20 >> The Internet works as well as it does precicely _because_ nobody >> gets too paranoid about how "accurate" packets are -- instead we >> spend our efforts worrying how well the implementations of our >> protocols "interoperate". (That keeps us busy enough, IMHO.) >>=20 >>> Only if you have that, you can think about implementing policies. >>=20 >> As an ISP, I "implement policies" all the time based upon guesswork. >> The general principle is that a partly-wrong policy implemented at = the >> right time is almost always better than a "right" policy implemented >> too late. >>=20 >>> Having said that, it is certainly implementation-specific how >>> auditing really works -- there may be tradeoffs between efficiency >>> and effectiveness -- but for the sake of the discussion here, I'd >>> say it's best to assume that, yes, auditing evaluates every packet. >>=20 >> IMHO, it's _always_ best to assume otherwise. >=20 > My view is that we're arguing the wrong point - auditing every packet = seems trivial if we are assuming that most routers can mark a packet = (e.g. can do ECN). In that case they are already inspecting 2 bits of = the IP header, so asking them to inspect a 3rd bit seems reasonable. = However, on a per-packet basis audit is meaningless. Audit only has any = meaning over a period of time across a given flow (or set of flows). = There is a separate accounting mechanism where you can measure bulk = flows of congestion, but that has to be based on a belief in the = accuracy of the marking of the underlying individual flows. >=20 >>=20 >> Your life will be easier if you don't depend on assumptions which >> are likely to be false. >>=20 >> We'd do better, when discussing this, to get specific about how >> auditing might improve the use-cases we're pushing. >>=20 >> Unless I misread draft-ietf-conex-concepts-uses, our principle >> use case is Informing Traffic Management. I have posted before that >> the most important feature of ConEx marking (IMHO) is informing >> any node along the way that the sender is knowingly sending packets >> despite having reason to doubt that congestion has cleared. >>=20 >> Auditing does nothing to help here. The abusive thing to do is >> to _clear_ ConEx marks -- and auditing can't detect that. >=20 > No. ConEx is about a balance of markings. To cheat you fail to send = forward into the network sufficient ConEx markings to cover the = congestion your flow is causing (or has caused). So the function of = auditing is to check that the two numbers roughly match. And yes, this = is a very difficult problem to solve if you can't assume ECN is being = used. >=20 >=20 >>=20 >> I haven't yet argued a specific benefit to ECN-marking instead >> of dropping -- when I do, I'll be arguing for ECN-marking well >> before packets need to be dropped. I simply don't believe that any >> amount of auditing will convince providers to trust ConEx marking >> to mean these packets will never be dropped. >=20 > I don't think ConEx is ever meant to say to a provider "these packets = are honest so must never be dropped". ConEx is meant to provide a better = metric to network users to allow them to see the actual impact of any = given set of packets in terms of congestion caused. >=20 >>=20 >> Auditing, to tell truth, may or may not prove useful after we >> have done enough experiments. IMHO, if it proves useful we'll find >> that it's useful when done statistically, rather than on every >> packet. >=20 > I think this may point to the heart of the issue. Yes, you can sample = to do audit, but only if you assume a relatively high density of = markings. If ConEx info is unary encoded into packets then you can only = measure it by measuring long streams of the packets. If ConEx is a = specific number carried in each packet then sparse sampling may well = give you enough to be able to achieve the aims of audit. >=20 > Which brings me on to the aims of audit. To my mind there are two = possible aims. 1) to guarantee that every single packet, flow, = aggregation of traffic in the network has accurately declared their = congestion or 2) to act as a "speed camera" that catches a sufficiently = high proportion of infringements to ensure that senders don't risk = under-declaring their congestion. My own view is that the second is more = feasible in the real world, although the first might well be more = desirable. >=20 > Toby >=20 >>=20 >> -- >> John Leslie >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >>=20 --Apple-Mail=_E3AB3FA2-5AE7-4062-8807-674D5416E98E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: "T. Moncaster" <tm444@cam.ac.uk>
Subject: = Re: [conex] byte vs packet = counting
Date: 3 December 2011 10:10:52 GMT
To: John Leslie <john@jlc.net>
Cc: Dirk Kutscher = <Dirk.Kutscher@neclab.eu>, = ConEx IETF list <conex@ietf.org>

=
I have been purposely not contributing to this thread over the past = few weeks as I wasn't sure that more voices in the argument would = actually help things. However I feel things are now at a point where I = can contribute something (hopefully) useful.

On Dec 2 2011, John = Leslie wrote:

Dirk Kutscher <Dirk.Kutscher@neclab.eu> = wrote:
[John Leslie <john@jlc.net> = wrote:]
I sincerely hope Bob isn't = saying that an audit function has = to
evaluate= _every_ packet which passes = it!
Clearly, it at least has to be = able to do that, yes!

 Clearly, = _if_ it has to do that, we're extremely limited on = _where_
we can put an auditing = function. Auditing is not going to get built
into the hardware of 10-gig = routers.

Auditing is really a fundamental piece of the basic Conex = mechanism,

 I'd be = happy to discuss that. I see no reason to bother = auditing
if the entire path is = known to be free of congestion. Auditing = might
make sense if you expect = traffic you send to encounter congestion
later in the path, but only if you have some contractual = arrangement
calling for it. = (Otherwise, you can't know what the effect = of
ConEx marks may = be.)

I think there is a subtle difference between = stating that auditing is a fundamental part of ConEx and saying that = auditing can never be turned off. I would definitely agree that auditing = is required in any network where there are potential trust issues and = where you can't guarantee the whole-path network conditions. But I do = think there are cases where it could be turned off (for instance in = private corporate networks using conex as a means to control their = monthly network bills).


 Auditing = every packet is plausible near the sender and = receiver,
but not in the = backbone. I don't believe we have agreement = among
ourselves what a = receiver's uplink will do if their auditing = shows
"abuse" of ConEx = marking: so I don't see what auditing at the
sender's uplink can do and be confident it's the right = thing.

I agree, it seems hard to see how auditing = something when you are missing half the information is going to be hard. = There are possible arguments along the lines of an ISP might make a = decision that all users of a given access node (B-RAS or whatever) are = likely to be experiencing roughly similar amounts of congestion. So any = customer that declares no congestion is probably not being = honest.


 I suppose it's possible the experiments we do will = enlighten
that question, but = I'm not confident. :^(

and has nothing to do with policy. Auditing is the basis = for accurate
congestion = exposure.

 The = Internet works as well as it does precicely _because_ = nobody
gets too paranoid about = how "accurate" packets are -- instead we
spend our efforts worrying how well the implementations of = our
protocols "interoperate". = (That keeps us busy enough, IMHO.)

Only if you have that, you can think about implementing = policies.

 As an = ISP, I "implement policies" all the time based upon = guesswork.
The general = principle is that a partly-wrong policy implemented at = the
right time is almost = always better than a "right" policy = implemented
too = late.

Having said that, it is certainly implementation-specific = how
auditing really works -- there may be tradeoffs between = efficiency
and effectiveness -- but for the = sake of the discussion here, = I'd
say it's best to assume that, yes, auditing evaluates = every packet.

 IMHO, = it's _always_ best to assume otherwise.

My view is = that we're arguing the wrong point - auditing every packet seems trivial = if we are assuming that most routers can mark a packet (e.g. can do = ECN). In that case they are already inspecting 2 bits of the IP header, = so asking them to inspect a 3rd bit seems reasonable. However, on a = per-packet basis audit is meaningless. Audit only has any meaning over a = period of time across a given flow (or set of flows). There is a = separate accounting mechanism where you can measure bulk flows of = congestion, but that has to be based on a belief in the accuracy of the = marking of the underlying individual flows.


 Your = life will be easier if you don't depend on assumptions = which
are likely to be = false.

 We'd do = better, when discussing this, to get specific about = how
auditing might improve the = use-cases we're pushing.

 Unless I = misread draft-ietf-conex-concepts-uses, our = principle
use case is = Informing Traffic Management. I have posted before = that
the most important = feature of ConEx marking (IMHO) is informing
any node along the way that the sender is knowingly = sending packets
despite having = reason to doubt that congestion has cleared.

 Auditing = does nothing to help here. The abusive thing to do = is
to _clear_ ConEx marks -- = and auditing can't detect that.

No. ConEx is about a = balance of markings. To cheat you fail to send forward into the network = sufficient ConEx markings to cover the congestion your flow is causing = (or has caused). So the function of auditing is to check that the two = numbers roughly match. And yes, this is a very difficult problem to = solve if you can't assume ECN is being used.



 I = haven't yet argued a specific benefit to ECN-marking = instead
of dropping -- when I = do, I'll be arguing for ECN-marking well
before packets need to be dropped. I simply don't believe = that any
amount of auditing = will convince providers to trust ConEx = marking
to mean these packets = will never be dropped.

I don't think ConEx is ever = meant to say to a provider "these packets are honest so must never be = dropped". ConEx is meant to provide a better metric to network users to = allow them to see the actual impact of any given set of packets in terms = of congestion caused.


=  Auditing, to tell truth, may or may not prove useful after = we
have done enough = experiments. IMHO, if it proves useful we'll = find
that it's useful when = done statistically, rather than on every
packet.

I think this may point to the = heart of the issue. Yes, you can sample to do audit, but only if you = assume a relatively high density of markings. If ConEx info is unary = encoded into packets then you can only measure it by measuring long = streams of the packets. If ConEx is a specific number carried in each = packet then sparse sampling may well give you enough to be able to = achieve the aims of audit.

Which brings me on to the aims of = audit. To my mind there are two possible aims. 1) to guarantee that = every single packet, flow, aggregation of traffic in the network has = accurately declared their congestion or 2) to act as a "speed camera" = that catches a sufficiently high proportion of infringements to ensure = that senders don't risk under-declaring their congestion. My own view is = that the second is more feasible in the real world, although the first = might well be more desirable.

Toby


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


= --Apple-Mail=_E3AB3FA2-5AE7-4062-8807-674D5416E98E-- From mattmathis@google.com Mon Dec 5 10:09: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 481B521F8C65 for ; Mon, 5 Dec 2011 10:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA4yV8KmXINi for ; Mon, 5 Dec 2011 10:09:45 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F388821F8C32 for ; Mon, 5 Dec 2011 10:09:44 -0800 (PST) Received: by eekd4 with SMTP id d4so632303eek.31 for ; Mon, 05 Dec 2011 10:09:44 -0800 (PST) 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:x-system-of-record; bh=irpKS3LozBuO4KKvQst6aDxJzcy3WiZUwrYVaINvLG0=; b=UC4i7XLKV35GhoHa6eacGYLi9xmMJ6YMnR1fj6Aa4RgcOVWuQH/j0j9lCbYbK8+xbV ZyVJjpLV0/o1n3JEYDeA== Received: by 10.14.94.68 with SMTP id m44mr1281322eef.38.1323108584060; Mon, 05 Dec 2011 10:09:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.94.68 with SMTP id m44mr1281310eef.38.1323108583737; Mon, 05 Dec 2011 10:09:43 -0800 (PST) Received: by 10.213.19.77 with HTTP; Mon, 5 Dec 2011 10:09:43 -0800 (PST) In-Reply-To: <20111205113356.GJ31463@verdi> References: <4EC468D5.5040009@it.uc3m.es> <20111205113356.GJ31463@verdi> Date: Mon, 5 Dec 2011 10:09:43 -0800 Message-ID: From: Matt Mathis To: John Leslie Content-Type: multipart/alternative; boundary=bcaec52be593220b7604b35c39f1 X-System-Of-Record: true Cc: ConEx IETF list Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-03.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, 05 Dec 2011 18:09:47 -0000 --bcaec52be593220b7604b35c39f1 Content-Type: text/plain; charset=ISO-8859-1 John, most of your comments are right on the money. I will make the changes as suggested. There are a couple which I would rather call and discuss to see if I can find a way to make the document clearer rather than changing its intended meaning. I will send a more extensive response to the list after that conversation. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Mon, Dec 5, 2011 at 3:33 AM, John Leslie wrote: > marcelo bagnulo braun wrote: > > > > Please review the document and send comments before the 5th december. > > The overall effect of this document is that of an impenetrable > academic paper. :^( I'd prefer something more approachable. (Alas, I > have been busy the past few weeks, and didn't set aside enough time > to review it: thus I've missed the deadline by local time, though > not necessarily by "any-time-zone" rules. ;) > > This I-D contains a lot of good material. The organization is a > bit confusing, but IMHO would be good if we were more selective in > what we include. For one example, proxies are introduced but not > explained in sufficient detail. They do not strike me as in any way > necessary to the ConEx mechanism -- merely a potential tool to > speed deployment... > > I'd go a lot easier on the part about competing Congesiton-Control > algorithms. Our point is that there are many of them and we expect > more, with ConEx merely signaling the detected loss and/or ECN marks. > Specifically, I'd replace the third bullet in section 1 with something > like, "Some alternate CC algorithms use delay as an input. ConEx does > not treat delay as a measure of congestion, and is concerned only > with ECN marking and packet loss." > > I'd omit the paragraph before Figure 1: it introduces ideas better > introduced elsewhere. > > 1.1 Terminology > > "Congestion level" is used but not defined. > > 2 Requirements for the ConEx Signal > > In 2.a I strongly recommend removing mention of IPv4 -- it's outside > our charter. > > In 2.c "auditing" is used in a somewhat non-intuitive manner, to > mean a function which both derives information and acts upon it to > change the flow. I'd much rather introduce "auditing" as gathering > information, not policing. Thus I recommend against "must have a > capability of providing sufficient disincentives". As we gain > experience with ConEx, I expect disincentives will be found, but > it's premature to say here what they may turn out to be. > > In 2.d I fully agree that ConEx should include building "credit" > against congestion expected before the feedback time (likely to be > several RTTs). However (IMHO) it's not good to tie this to the > auditing function. > > We've already seen on-list some substantial confusion from this. > We have folks gravitating towards setting the "credit" bit on > every packet "just in case". This is not useful: a ConEx signal > which is always present is no more useful than a ConEx signal which > is never present. > > My strong opinion is that all nodes along the path should be > able to determine a "congestion-expected" metric which reasonably > tracks the congestion impairment for the flow in question. It's > premature (IMHO) to say just how to do this, but I think it would > be best to treat the "credit" signal as an "expectation" at the > start (or resumption) of a flow, which suggests that different > CC algorithms may choose to set it differently. Such details > shouldn't be nailed down too early. > > A general comment here: in a number of places in this I-D, > the reader trying to imagine how to implement ConEx will boggle > on how to implement the "auditing function". It seems to require > per-flow state at points along the path where this is wildly > impractical. > > I do not believe ConEx needs such a draconian function that > seems to be requiring high estimates for "credit". It's not that > I object to such a function _existing_ -- rather that this is > just _one_ way to use ConEx signals. Even if it is in fact the > best way, requiring it at the outset of Experimental phase scares > me. > > There is perhaps an unstated assumption that we can have > policing near the sender which will satisfy all nodes along the > path about the accuracy of congestion prediction. To an operator > this is laughable. > > My honest suggestion is to separate out any details of an > auditing function which includes policing into a separate document > which we can revise as we gain experience. Abstract-mech will be > stranger if it limits itself to how to signal the interesting > metrics, without tryinng to specify how to make them trustworthy. > > In any case, I recommend cutting back 2.d to something like, > "The ConEx signal SHOULD be timely. There will be a minimum delay > of one RTT, and often it will be longer. In order for nodes along > the path to ignore this delay, ConEx signals SHOULD include a > "credit" signal to cover congestion (not yet measured) during > this delay." > > The information about ECN congestion being best audited near > the receiver, etc., is important, but deserves its own section > later in the document. Personally, I'd leave out all mention of > how to infer loss at an auditing point. It's not IMHO a _ConEx_ > mechanism -- it's a research topic during experiments. While > Matt and Bob may be right that this is the best way to do it, > the world is more complicated than we _can_ imagine and I expect > our readers to imagine lots of alternatives. > > The statement about signaling loss separately from ECN is > critically important IMHO, and very much deserves its own section. > Though we may not want to go into detail about differing AQM > algorithms and parameters, these are an important part of what > should be tried during experiments, and I'd like to hint more > at that. > > (To digress, DCTCP for example uses AQM parameters to signal > queue depth much more aggressively than the ECN standard implies, > and this turns out to be very useful in the limited environment > where DCTCP is used. There is almost certainly an opportunity to > develop somewhat similar AQM signaling in the big-I Internet, > where ECN marking could be common at nodes where packet loss is > quite rare. We cannot make such changes to ECN in this WG as > currently chartered; but I'd like to leave room to develop > experiments in that direction.) > > 3. Encoding Congestion Exposure > > I'd omit entirely the "Naive Encoding". For academic papers, this > would be helpful, but here we need to get to the point. We're going > to end up with at least 4 independent bits: it can't help implementors > that we dwell on alternatives. (So 3.1 shouldn't be a separate section.) > > 3.2 ECN Based Encoding > > Talking of sharing ECN codepoints only confuses the reader. It > can't be understood without going into a lot of re-ECN details, and > that's not the path we will take. I'd omit 3.2. > > The ECN changes section mention of a "different state machine" > is particularly confusing, but I don't believe it is needed for > ConEx. (If it is, it needs a lot more explanation.) > > Section 3.3 feels like the right introduction. > > Section 3.3.1 should match the actual naming of the independent > bits, if possible. If we maintain "abstract-mech" as an I-D, we > can change these if needed without needing to revisit the whole > document. > > Section 3.3.2 should be deleted -- we're not going to recommend > this. > > 4. Congestion Exposure Components > > I dissent on assigning a policing role to the "auditing function". > "Auditing" and "Policing" were kept separate in use-cases while I > was on the editing team, and I strongly recommend keeping the separate > still. Eventually, they may belong in the same box, but auditing with > no policing will remain a useful function. > > I further suggest that mandating the two be combined does not > belong in an "Abstract Mechanism" document. Nor is the policing > function made any easier to understand by forcing this combination. > I'd prefer that any details of auditing and/or policing be in a > separate document, and abstract-mech merely refer to it as an > optional addition to the basic mechanism. > > Arguments that ConEx is useless without policing don't convince me. > If true, ConEx would be just as useless without trustworthy policing, > and to an ISP any policing done by a competitor is by definition > untrustworthy. > > Most of the rest of Section 4 is pretty good. I'm a bit nervous > about seeming to require ECN-feedback changes, but I don't think the > text intends to actually require them. I'd be happier if all of > Section 4.4 (including 4.4.1 and 4.4.2) disappeared into a separate > document. > > 4.5 Policy Devices > > This is rather good, but I wonder how well it represents an actual > consensus of this WG -- I'd feel more comfortable with a record of > discussion in the archives of this mailing-list. While I don't > disagree with 4.5.2, I'm uncertain how many of us want to try this. > > In 4.5.3, I'm actively uncomfortable with the term "Congestion > Policer". To me, this is describing a particular case of a Policy > Device, and is by no means the only "policing" function a Policy > Device might do. Perhaps we could find another term along the lines > of "Packet Sorter". > > The implication needed is that at any organizational boundary > it's reasonable to limit the "congestion-expected" that you allow > into your network. (Whether you limit by bytes, packet, or some > combination is a local decision hopefully covered by contractual > agreements.) When presented with traffic which exceeds such limits, > reducing the scheduling priority or selectively dropping packets > is reasonable (though of course not _required_ by ConEx protocol). > > (The use of "Not-ConEx-Marked" may or may not be right in this > paragraph: I have not tried to work that out. IMHO any such details > are local, and other sorting algorithms seem allowable.) > > 5. Support for Incremental Deployment > > There's a lot of good stuff here... perhaps too much. I would, > for example, omit any mention of proxies. > > I could go into a lot more detail, but I think this email is > long enough. > > 7. Security Considerations > > This section needs actual discussion of some threats. (The less we > promise, the less threats we need to discuss!) > > 8. Conclusions > > This isn't needed as a section in an Internet-Draft. > > 11.2. Informative References > > I appreciate the joke, but do we really want to reference RFC3514? > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > --bcaec52be593220b7604b35c39f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John, most of your comments are right on the money. =A0I will make the chan= ges as suggested. =A0 =A0There are a couple which I would rather call and d= iscuss to see if I can find a way to make the document clearer rather than = changing its intended meaning.

I will send a more extensive response to the list after that= =A0conversation.

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



On Mon, Dec 5, 2011 at 3:33 AM, John Les= lie <john@jlc.net&= gt; wrote:
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
>
> Please review the document and send comments b= efore the 5th december.

=A0 The overall effect of this document is that of an impenetrable academic paper. :^( I'd prefer something more approachable. (Alas, I have been busy the past few weeks, and didn't set aside enough time
to review it: thus I've missed the deadline by local time, though
not necessarily by "any-time-zone" rules. ;)

=A0 This I-D contains a lot of good material. The organization is a
bit confusing, but IMHO would be good if we were more selective in
what we include. For one example, proxies are introduced but not
explained in sufficient detail. They do not strike me as in any way
necessary to the ConEx mechanism -- merely a potential tool to
speed deployment...

=A0 I'd go a lot easier on the part about competing Congesiton-Control=
algorithms. Our point is that there are many of them and we expect
more, with ConEx merely signaling the detected loss and/or ECN marks.
Specifically, I'd replace the third bullet in section 1 with something<= br> like, "Some alternate CC algorithms use delay as an input. ConEx does<= br> not treat delay as a measure of congestion, and is concerned only
with ECN marking and packet loss."

=A0 I'd omit the paragraph before Figure 1: it introduces ideas better=
introduced elsewhere.

1.1 Terminology

=A0 "Congestion level" is used but not defined.

2 Requirements for the ConEx Signal

=A0 In 2.a I strongly recommend removing mention of IPv4 -- it's outsi= de
our charter.

=A0 In 2.c "auditing" is used in a somewhat non-intuitive manner= , to
mean a function which both derives information and acts upon it to
change the flow. I'd much rather introduce "auditing" as gath= ering
information, not policing. Thus I recommend against "must have a
capability of providing sufficient disincentives". As we gain
experience with ConEx, I expect disincentives will be found, but
it's premature to say here what they may turn out to be.

=A0 In 2.d I fully agree that ConEx should include building "credit&q= uot;
against congestion expected before the feedback time (likely to be
several RTTs). However (IMHO) it's not good to tie this to the
auditing function.

=A0 We've already seen on-list some substantial confusion from this. We have folks gravitating towards setting the "credit" bit on
every packet "just in case". This is not useful: a ConEx signal which is always present is no more useful than a ConEx signal which
is never present.

=A0 My strong opinion is that all nodes along the path should be
able to determine a "congestion-expected" metric which reasonably=
tracks the congestion impairment for the flow in question. It's
premature (IMHO) to say just how to do this, but I think it would
be best to treat the "credit" signal as an "expectation"= ; at the
start (or resumption) of a flow, which suggests that different
CC algorithms may choose to set it differently. Such details
shouldn't be nailed down too early.

=A0 A general comment here: in a number of places in this I-D,
the reader trying to imagine how to implement ConEx will boggle
on how to implement the "auditing function". It seems to require<= br> per-flow state at points along the path where this is wildly
impractical.

=A0 I do not believe ConEx needs such a draconian function that
seems to be requiring high estimates for "credit". It's not t= hat
I object to such a function _existing_ -- rather that this is
just _one_ way to use ConEx signals. Even if it is in fact the
best way, requiring it at the outset of Experimental phase scares
me.

=A0 There is perhaps an unstated assumption that we can have
policing near the sender which will satisfy all nodes along the
path about the accuracy of congestion prediction. To an operator
this is laughable.

=A0 My honest suggestion is to separate out any details of an
auditing function which includes policing into a separate document
which we can revise as we gain experience. Abstract-mech will be
stranger if it limits itself to how to signal the interesting
metrics, without tryinng to specify how to make them trustworthy.

=A0 In any case, I recommend cutting back 2.d to something like,
"The ConEx signal SHOULD be timely. There will be a minimum delay
of one RTT, and often it will be longer. In order for nodes along
the path to ignore this delay, ConEx signals SHOULD include a
"credit" signal to cover congestion (not yet measured) during
this delay."

=A0 The information about ECN congestion being best audited near
the receiver, etc., is important, but deserves its own section
later in the document. Personally, I'd leave out all mention of
how to infer loss at an auditing point. It's not IMHO a _ConEx_
mechanism -- it's a research topic during experiments. While
Matt and Bob may be right that this is the best way to do it,
the world is more complicated than we _can_ imagine and I expect
our readers to imagine lots of alternatives.

=A0 The statement about signaling loss separately from ECN is
critically important IMHO, and very much deserves its own section.
Though we may not want to go into detail about differing AQM
algorithms and parameters, these are an important part of what
should be tried during experiments, and I'd like to hint more
at that.

=A0 (To digress, DCTCP for example uses AQM parameters to signal
queue depth much more aggressively than the ECN standard implies,
and this turns out to be very useful in the limited environment
where DCTCP is used. There is almost certainly an opportunity to
develop somewhat similar AQM signaling in the big-I Internet,
where ECN marking could be common at nodes where packet loss is
quite rare. We cannot make such changes to ECN in this WG as
currently chartered; but I'd like to leave room to develop
experiments in that direction.)

3. Encoding Congestion Exposure

=A0 I'd omit entirely the "Naive Encoding". For academic pap= ers, this
would be helpful, but here we need to get to the point. We're going
to end up with at least 4 independent bits: it can't help implementors<= br> that we dwell on alternatives. (So 3.1 shouldn't be a separate section.= )

3.2 ECN Based Encoding

=A0 Talking of sharing ECN codepoints only confuses the reader. It
can't be understood without going into a lot of re-ECN details, and
that's not the path we will take. I'd omit 3.2.

=A0 The ECN changes section mention of a "different state machine&quo= t;
is particularly confusing, but I don't believe it is needed for
ConEx. (If it is, it needs a lot more explanation.)

=A0 Section 3.3 feels like the right introduction.

=A0 Section 3.3.1 should match the actual naming of the independent
bits, if possible. If we maintain "abstract-mech" as an I-D, we can change these if needed without needing to revisit the whole
document.

=A0 Section 3.3.2 should be deleted -- we're not going to recommend this.

4. Congestion Exposure Components

=A0 I dissent on assigning a policing role to the "auditing function&= quot;.
"Auditing" and "Policing" were kept separate in use-cas= es while I
was on the editing team, and I strongly recommend keeping the separate
still. Eventually, they may belong in the same box, but auditing with
no policing will remain a useful function.

=A0 I further suggest that mandating the two be combined does not
belong in an "Abstract Mechanism" document. Nor is the policing function made any easier to understand by forcing this combination.
I'd prefer that any details of auditing and/or policing be in a
separate document, and abstract-mech merely refer to it as an
optional addition to the basic mechanism.

=A0 Arguments that ConEx is useless without policing don't convince me= .
If true, ConEx would be just as useless without trustworthy policing,
and to an ISP any policing done by a competitor is by definition
untrustworthy.

=A0 Most of the rest of Section 4 is pretty good. I'm a bit nervous about seeming to require ECN-feedback changes, but I don't think the text intends to actually require them. I'd be happier if all of
Section 4.4 (including 4.4.1 and 4.4.2) disappeared into a separate
document.

4.5 Policy Devices

=A0 This is rather good, but I wonder how well it represents an actual
consensus of this WG -- I'd feel more comfortable with a record of
discussion in the archives of this mailing-list. While I don't
disagree with 4.5.2, I'm uncertain how many of us want to try this.

=A0 In 4.5.3, I'm actively uncomfortable with the term "Congestio= n
Policer". To me, this is describing a particular case of a Policy
Device, and is by no means the only "policing" function a Policy<= br> Device might do. Perhaps we could find another term along the lines
of "Packet Sorter".

=A0 The implication needed is that at any organizational boundary
it's reasonable to limit the "congestion-expected" that you a= llow
into your network. (Whether you limit by bytes, packet, or some
combination is a local decision hopefully covered by contractual
agreements.) When presented with traffic which exceeds such limits,
reducing the scheduling priority or selectively dropping packets
is reasonable (though of course not _required_ by ConEx protocol).

=A0 (The use of "Not-ConEx-Marked" may or may not be right in th= is
paragraph: I have not tried to work that out. IMHO any such details
are local, and other sorting algorithms seem allowable.)

5. Support for Incremental Deployment

=A0 There's a lot of good stuff here... perhaps too much. I would,
for example, omit any mention of proxies.

=A0 I could go into a lot more detail, but I think this email is
long enough.

7. Security Considerations

=A0 This section needs actual discussion of some threats. (The less we
promise, the less threats we need to discuss!)

8. Conclusions

=A0 This isn't needed as a section in an Internet-Draft.

11.2. Informative References

=A0 I appreciate the joke, but do we really want to reference RFC3514?

--
John Leslie <john@jlc.net>
_____________________= __________________________
conex mailing list
conex@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/conex

--bcaec52be593220b7604b35c39f1-- From john@jlc.net Mon Dec 5 15:01: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 A90B521F8B38 for ; Mon, 5 Dec 2011 15:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.71 X-Spam-Level: X-Spam-Status: No, score=-106.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeoWhOtQMS6m for ; Mon, 5 Dec 2011 15:01:53 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8F48A21F8B33 for ; Mon, 5 Dec 2011 15:01:53 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id ADBB033C21; Mon, 5 Dec 2011 18:01:53 -0500 (EST) Date: Mon, 5 Dec 2011 18:01:53 -0500 From: John Leslie To: "T. Moncaster" Message-ID: <20111205230153.GC39149@verdi> References: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> <20111202232051.GH31463@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 list Subject: Re: [conex] byte vs packet counting 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, 05 Dec 2011 23:01:55 -0000 T. Moncaster wrote: > > I have been purposely not contributing to this thread over the past few > weeks as I wasn't sure that more voices in the argument would actually > help things. IMHO, _any_ additional voices would help. (Of course, I may be biased: if nobody takes my ideas seriously it's easier to declare me "in the rough"...) > However I feel things are now at a point where I can contribute > something (hopefully) useful. Toby has _always_ had something useful to contribute!! > On Dec 2 2011, John Leslie wrote: >> Dirk Kutscher wrote: >>> [John Leslie wrote:] >>> >>> Auditing is really a fundamental piece of the basic Conex mechanism, >> >> I'd be happy to discuss that. I see no reason to bother auditing >> if the entire path is known to be free of congestion. Auditing might >> make sense if you expect traffic you send to encounter congestion >> later in the path, but only if you have some contractual arrangement >> calling for it. (Otherwise, you can't know what the effect of >> ConEx marks may be.) > > I think there is a subtle difference between stating that auditing > is a fundamental part of ConEx and saying that auditing can never > be turned off. Agreed... but it's not obvious which of these Dirk meant. :^( > I would definitely agree that auditing is required in any network > where there are potential trust issues and where you can't guarantee > the whole-path network conditions. In other words, any real-world network... > But I do think there are cases where it could be turned off (for > instance in private corporate networks using conex as a means to > control their monthly network bills). Is that really so different from real-world networks? (An aside: I talked with Matt today, and we're making progress on understanding each other on what the WG should mean by "auditing". Stay tuned...) >> Auditing every packet is plausible near the sender and receiver, >> but not in the backbone. I don't believe we have agreement among >> ourselves what a receiver's uplink will do if their auditing shows >> "abuse" of ConEx marking: so I don't see what auditing at the >> sender's uplink can do and be confident it's the right thing. > > I agree, it seems hard to see how auditing something when you are > missing half the information is going to be hard. (I'm having trouble parsing that sentence.) > There are possible arguments along the lines of an ISP might make > a decision that all users of a given access node (B-RAS or whatever) > are likely to be experiencing roughly similar amounts of congestion. (Seems unlikely to me...) > So any customer that declares no congestion is probably not being > honest. This sort of assumption bothers me. What if that customer is using a particularly good LBE protocol? >>> Having said that, it is certainly implementation-specific how >>> auditing really works -- there may be tradeoffs between efficiency >>> and effectiveness -- but for the sake of the discussion here, I'd >>> say it's best to assume that, yes, auditing evaluates every packet. >> >> IMHO, it's _always_ best to assume otherwise. > > My view is that we're arguing the wrong point - auditing every packet > seems trivial if we are assuming that most routers can mark a packet > (e.g. can do ECN). In that case they are already inspecting 2 bits of > the IP header, so asking them to inspect a 3rd bit seems reasonable. (Talking with Matt today, I am beginning to understand he may be assuming that "auditing" measures only ConEx marks versus ECN marks for a particular packet; and that the action taken on that basis will be simply and only dropping the packet where the imbalance is detected, keeping no state. That much could be implemented anywhere; but it falls far short of what we are led to believe is promised by his "auditing function". I'm hoping the next revision will assign more intuitive names to whatever his current "auditing function" proposes...) > However, on a per-packet basis audit is meaningless. I think I agree with Toby. > Audit only has any meaning over a period of time across a given flow > (or set of flows). There's a pretty big difference between auditing a particular flow versus auditing the particular set of flows represented by all traffic an ISP receives from a peer at a peering point... I'm not sure exactly what Toby refers to here. > There is a separate accounting mechanism where you can measure bulk > flows of congestion, but that has to be based on a belief in the > accuracy of the marking of the underlying individual flows. I don't see how that follows. >> Your life will be easier if you don't depend on assumptions which >> are likely to be false. >> >> We'd do better, when discussing this, to get specific about how >> auditing might improve the use-cases we're pushing. >> >> Unless I misread draft-ietf-conex-concepts-uses, our principle >> use case is Informing Traffic Management. I have posted before that >> the most important feature of ConEx marking (IMHO) is informing >> any node along the way that the sender is knowingly sending packets >> despite having reason to doubt that congestion has cleared. >> >> Auditing does nothing to help here. The abusive thing to do is >> to _clear_ ConEx marks -- and auditing can't detect that. > > No. ConEx is about a balance of markings. To cheat you fail to send > forward into the network sufficient ConEx markings to cover the > congestion your flow is causing (or has caused). Not quite... an ISP can cheat by clearing marks which one sender placed in his outgoing traffic -- that is what I meant to refer to. > So the function of auditing is to check that the two numbers > roughly match. (I note that Toby says "roughly match". Others seem to be assuming a much stricter match. I'm afraid we don't have a clear understanding here.) > And yes, this is a very difficult problem to solve if you can't > assume ECN is being used. I absolutely agree with Toby here. >> Auditing, to tell truth, may or may not prove useful after we >> have done enough experiments. IMHO, if it proves useful we'll find >> that it's useful when done statistically, rather than on every >> packet. > > I think this may point to the heart of the issue. Yes, you can sample > to do audit, but only if you assume a relatively high density of > markings. I don't follow why that is true. If auditing is not strict, sampling should work for a wide range of density; if auditing is strict, it will fail pretty much regardless of the density... > If ConEx info is unary encoded into packets then you can only measure > it by measuring long streams of the packets. I agree with what I think Toby intends to say: that the congestion metric of ConEx is a fraction, not a binary function per packet. > If ConEx is a specific number carried in each packet then sparse > sampling may well give you enough to be able to achieve the aims of > audit. Carrying what I call "congestion-expected" as a multi-bit fraction is an interesting idea, in which I see potential benefits. I'd be happy to discuss it, but my impression is that we're not heading in that direction. > Which brings me on to the aims of audit. To my mind there are two > possible aims. > 1) to guarantee that every single packet, flow, aggregation of traffic > in the network has accurately declared their congestion; or > 2) to act as a "speed camera" that catches a sufficiently high > proportion of infringements to ensure that senders don't risk > under-declaring their congestion. I don't see auditing as either of these; but that may be more a function of my tendency to think of auditing as gathering information, not enforcing disciplinary measures based on this information. IMHO, "guaranteeing" much of anything isn't worth the effort over organizational boundaries. At significant expense, we could use cryptography to give arbitrarily high confidence to a particular "guarantee" having come from a particular entity, but without also signing the data "guaranteed", the effort is entirely wasted. (And processing all that cryptography in backbone routers seems a non-starter to me.) > My own view is that the second is more feasible in the real world, > although the first might well be more desirable. I at least partly agree here. However, my approach to thinking about such problems simply stops descending into details when I reach a feasibility blockage. -- John Leslie From tm444@hermes.cam.ac.uk Tue Dec 6 01:50: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 7142121F8B14 for ; Tue, 6 Dec 2011 01:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF1allNroO57 for ; Tue, 6 Dec 2011 01:50:30 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id ABC3221F8B12 for ; Tue, 6 Dec 2011 01:50:29 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:61300) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1RXrfP-0001VO-X1 (Exim 4.72) (return-path ); Tue, 06 Dec 2011 09:50:27 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster In-Reply-To: <20111205230153.GC39149@verdi> Date: Tue, 6 Dec 2011 09:50:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD81879-81A2-4EF0-A60B-F541D0BA418B@cl.cam.ac.uk> References: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> <20111202232051.GH31463@verdi> <20111205230153.GC39149@verdi> To: John Leslie X-Mailer: Apple Mail (2.1251.1) Sender: "T. Moncaster" Cc: "T. Moncaster" , ConEx IETF list Subject: Re: [conex] byte vs packet counting 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, 06 Dec 2011 09:50:31 -0000 On 5 Dec 2011, at 23:01, John Leslie wrote: > T. Moncaster wrote: >>=20 >> I have been purposely not contributing to this thread over the past = few=20 >> weeks as I wasn't sure that more voices in the argument would = actually >> help things. >=20 > IMHO, _any_ additional voices would help. (Of course, I may be = biased: > if nobody takes my ideas seriously it's easier to declare me "in the > rough"...) >=20 >> However I feel things are now at a point where I can contribute >> something (hopefully) useful. >=20 > Toby has _always_ had something useful to contribute!! >=20 >> On Dec 2 2011, John Leslie wrote: >>> Dirk Kutscher wrote: >>>> [John Leslie wrote:] >>>>=20 >>>> Auditing is really a fundamental piece of the basic Conex = mechanism, >>>=20 >>> I'd be happy to discuss that. I see no reason to bother auditing >>> if the entire path is known to be free of congestion. Auditing might >>> make sense if you expect traffic you send to encounter congestion >>> later in the path, but only if you have some contractual arrangement >>> calling for it. (Otherwise, you can't know what the effect of >>> ConEx marks may be.) >>=20 >> I think there is a subtle difference between stating that auditing >> is a fundamental part of ConEx and saying that auditing can never >> be turned off.=20 >=20 > Agreed... but it's not obvious which of these Dirk meant. :^( >=20 >> I would definitely agree that auditing is required in any network >> where there are potential trust issues and where you can't guarantee >> the whole-path network conditions. >=20 > In other words, any real-world network=85 indeed >=20 >> But I do think there are cases where it could be turned off (for >> instance in private corporate networks using conex as a means to >> control their monthly network bills). >=20 > Is that really so different from real-world networks? The main difference is that they may have an additional "big stick" that = they can beat their users with if they are found to have cheated. In = other words you can make the trust separate issue. >=20 > (An aside: I talked with Matt today, and we're making progress on > understanding each other on what the WG should mean by "auditing". > Stay tuned=85) That sounds like an interesting chat - looking forward to seeing the = output of it. >=20 >>> Auditing every packet is plausible near the sender and receiver, >>> but not in the backbone. I don't believe we have agreement among >>> ourselves what a receiver's uplink will do if their auditing shows >>> "abuse" of ConEx marking: so I don't see what auditing at the >>> sender's uplink can do and be confident it's the right thing. >>=20 >> I agree, it seems hard to see how auditing something when you are >> missing half the information is going to be hard. >=20 > (I'm having trouble parsing that sentence.) I think we are hitting the issue of "what is audit?" If audit is taken = to mean accounting for ConEx marks, then that can happen anywhere. = However I was taking auditing to mean accounting for the balance of = ConEx marks with actual congestion. That function can only work = somewhere where you can see both the congestion and the ConEx marks. The = only way you can achieve that at the sender side is by inspecting the = ACKs on the return path (which may be impossible). >=20 >> There are possible arguments along the lines of an ISP might make >> a decision that all users of a given access node (B-RAS or whatever) >> are likely to be experiencing roughly similar amounts of congestion. >=20 > (Seems unlikely to me=85) Oh, patently unlikely, but it is the sort of thing I can (sadly) imagine = some ISPs doing. >=20 >> So any customer that declares no congestion is probably not being >> honest. >=20 > This sort of assumption bothers me. What if that customer is using > a particularly good LBE protocol? Well quite - that is the argument against blanket rate limiting of all = P2P, even if it is running on LBE transport. >=20 >>>> Having said that, it is certainly implementation-specific how >>>> auditing really works -- there may be tradeoffs between efficiency >>>> and effectiveness -- but for the sake of the discussion here, I'd >>>> say it's best to assume that, yes, auditing evaluates every packet. >>>=20 >>> IMHO, it's _always_ best to assume otherwise. >>=20 >> My view is that we're arguing the wrong point - auditing every packet >> seems trivial if we are assuming that most routers can mark a packet >> (e.g. can do ECN). In that case they are already inspecting 2 bits of >> the IP header, so asking them to inspect a 3rd bit seems reasonable. >=20 > (Talking with Matt today, I am beginning to understand he may be > assuming that "auditing" measures only ConEx marks versus ECN marks > for a particular packet; and that the action taken on that basis > will be simply and only dropping the packet where the imbalance is > detected, keeping no state. That much could be implemented anywhere; > but it falls far short of what we are led to believe is promised by > his "auditing function". I'm hoping the next revision will assign > more intuitive names to whatever his current "auditing function" > proposes=85) That has been sort of my assumption, but with the proviso that you can = only really tell the imbalance over a set of packets (see below) >=20 >> However, on a per-packet basis audit is meaningless. >=20 > I think I agree with Toby. >=20 >> Audit only has any meaning over a period of time across a given flow >> (or set of flows). >=20 > There's a pretty big difference between auditing a particular > flow versus auditing the particular set of flows represented by all > traffic an ISP receives from a peer at a peering point... I'm not > sure exactly what Toby refers to here. Audit has two granularities - either you are auditing a given user to = ensure his flow (or flows if he is using several) are correctly = reporting the expected level of congestion, or you are auditing a whole = peer network to ensure they aren't allowing excess congestion to enter = your network without it being declared. These require (subtly?) = different audit mechanisms >=20 >> There is a separate accounting mechanism where you can measure bulk >> flows of congestion, but that has to be based on a belief in the >> accuracy of the marking of the underlying individual flows. >=20 > I don't see how that follows. Measuring the bulk is very easy, but if all the flows making up the bulk = are understating their congestion then the bulk will be understated as = well. Bob always had in mind a clever mechanism to do spot checking at = any border to identify persistent under (or over) declaration, but I = never entirely understood how it was meant to work. >=20 >>> Your life will be easier if you don't depend on assumptions which >>> are likely to be false. >>>=20 >>> We'd do better, when discussing this, to get specific about how >>> auditing might improve the use-cases we're pushing. >>>=20 >>> Unless I misread draft-ietf-conex-concepts-uses, our principle >>> use case is Informing Traffic Management. I have posted before that >>> the most important feature of ConEx marking (IMHO) is informing >>> any node along the way that the sender is knowingly sending packets >>> despite having reason to doubt that congestion has cleared. >>>=20 >>> Auditing does nothing to help here. The abusive thing to do is >>> to _clear_ ConEx marks -- and auditing can't detect that. >>=20 >> No. ConEx is about a balance of markings. To cheat you fail to send >> forward into the network sufficient ConEx markings to cover the >> congestion your flow is causing (or has caused). >=20 > Not quite... an ISP can cheat by clearing marks which one sender > placed in his outgoing traffic -- that is what I meant to refer to. OK, yes. That is a separate requirement for audit.=20 >=20 >> So the function of auditing is to check that the two numbers >> roughly match. >=20 > (I note that Toby says "roughly match". Others seem to be assuming > a much stricter match. I'm afraid we don't have a clear understanding > here.) Clearly, given the min 1RTT delay between getting congestion info and = responding to it, there can never be a completely accurate match. I did = have numerous debates with Bob about this topic. Basically you run the = risk of a user just terminating his flow rather than making up his = losses. You also have to be cautious that the actual process of dropping = packets for audit doesn't simply distort the apparent congestion = information (because the sender will respond by retransmitting and = hopefully adding more ConEx marks) >=20 >> And yes, this is a very difficult problem to solve if you can't >> assume ECN is being used. >=20 > I absolutely agree with Toby here. >=20 >>> Auditing, to tell truth, may or may not prove useful after we >>> have done enough experiments. IMHO, if it proves useful we'll find >>> that it's useful when done statistically, rather than on every >>> packet. >>=20 >> I think this may point to the heart of the issue. Yes, you can sample >> to do audit, but only if you assume a relatively high density of >> markings. >=20 > I don't follow why that is true. If auditing is not strict, sampling > should work for a wide range of density; if auditing is strict, it > will fail pretty much regardless of the density=85 OK, this comes down to the point below >=20 >> If ConEx info is unary encoded into packets then you can only measure >> it by measuring long streams of the packets. >=20 > I agree with what I think Toby intends to say: that the congestion > metric of ConEx is a fraction, not a binary function per packet. Which follows very naturally from ECN - ECN (RED) randomly decides = whether or not to mark a packet, with the aim that the overall number of = marks (very roughly) reflects the congestion level experienced at that = queue. Because this is a random unary scheme, any ConEx mechanism based = on ECN (and that is trying to audit against current network conditions) = will need to track this over a few packets to see how many ConEx marks = it should expect. OR the sender has to have sent sufficient credit up = front. Even in a scheme that is trying to identify either gaps in sequence = space (dangerous - especially in an MPTCP world) or is trying to = identify retransmissions (again, dangerous in MPTCP), then you have to = have some sort of memory of what went before (a counter of congestion = seen against ConEx credit seen for instance). >=20 >> If ConEx is a specific number carried in each packet then sparse >> sampling may well give you enough to be able to achieve the aims of >> audit. >=20 > Carrying what I call "congestion-expected" as a multi-bit fraction > is an interesting idea, in which I see potential benefits. I'd be > happy to discuss it, but my impression is that we're not heading in > that direction. That was certainly how I understood a re-ECN like scheme working=85 Te = whole core of this argument (should you account for bytes or packets) = has always been a major bone of contention between me and Bob. Not least = because it can be impossible for a sender to comply (it is very easy to = construct pathological sequences of packets where the sender is forced = to either over or under declare if they are doing per-byte auditing). I = think this is a case where the IETF view has to diverge from the = researcher's view. In the IETF we have to make prosaic engineering = decisions. Personally I would like ConEx to account on a per-packet = basis, BUT with an allowance for it to be more accurate if an operator = so wishes (in other words MUST as a minimum account per packet, but MAY = account per byte) >=20 >> Which brings me on to the aims of audit. To my mind there are two >> possible aims. >> 1) to guarantee that every single packet, flow, aggregation of = traffic >> in the network has accurately declared their congestion; or >> 2) to act as a "speed camera" that catches a sufficiently high >> proportion of infringements to ensure that senders don't risk >> under-declaring their congestion. >=20 > I don't see auditing as either of these; but that may be more a > function of my tendency to think of auditing as gathering information, > not enforcing disciplinary measures based on this information. Perhaps auditing is an unhelpful word to use. To my mind an audit = implies an accountancy audit that tries to balance the books. I agree = that carries no implication of policing or enforcement, but I think that = a lot of this debate has assumed the two concepts are identical >=20 > IMHO, "guaranteeing" much of anything isn't worth the effort over > organizational boundaries. At significant expense, we could use > cryptography to give arbitrarily high confidence to a particular > "guarantee" having come from a particular entity, but without also > signing the data "guaranteed", the effort is entirely wasted. >=20 > (And processing all that cryptography in backbone routers seems > a non-starter to me.) Agreed, this has to be a lightweight mechanism. All the guarantees have = to come from the idea that operators have to have some level of trust = among one another (or at least, the realisation that an operator found = to have cheated at the expense of others runs risk of getting sat on = heavily by the others), >=20 >> My own view is that the second is more feasible in the real world, >> although the first might well be more desirable. >=20 > I at least partly agree here. However, my approach to thinking > about such problems simply stops descending into details when I reach > a feasibility blockage. And therein lies the lesson for ConEx. We HAVE to fix on a SIMPLE subset = of ConEx that we can all agree on and that seems at least feasible in = the real world. Arguments like the recent ones make ConEx appear to be = still firmly stuck in the land of research (IRTF). Too many people (on = all sides of all arguments) seem to want perfection and that is not = sensible in the real world. That is just a recipe for ratholing = ourselves to the point where the IESG declares our WG dysfunctional=85=20= Toby >=20 > -- > John Leslie From bob.briscoe@bt.com Tue Dec 13 12:12: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 43D5521F8AF2 for ; Tue, 13 Dec 2011 12:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD2cdrPBfxn3 for ; Tue, 13 Dec 2011 12:12:57 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6090D21F8A70 for ; Tue, 13 Dec 2011 12:12:57 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Dec 2011 20:12:54 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Dec 2011 20:12:54 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1323807192749; Tue, 13 Dec 2011 20:13:12 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.64.78]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id pBDKCokX014681; Tue, 13 Dec 2011 20:12:50 GMT Message-Id: <201112132012.pBDKCokX014681@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Dec 2011 20:12:50 +0000 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <9BD81879-81A2-4EF0-A60B-F541D0BA418B@cl.cam.ac.uk> References: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> <20111202232051.GH31463@verdi> <20111205230153.GC39149@verdi> <9BD81879-81A2-4EF0-A60B-F541D0BA418B@cl.cam.ac.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: 13 Dec 2011 20:12:54.0416 (UTC) FILETIME=[9910E100:01CCB9D3] Cc: "T. Moncaster" , ConEx IETF list Subject: Re: [conex] byte vs packet counting 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, 13 Dec 2011 20:12:59 -0000 Toby, Catching up after been away for a week... Inline, and I've snipped everything I agree with... At 09:50 06/12/2011, Toby Moncaster wrote: >On 5 Dec 2011, at 23:01, John Leslie wrote: > > T. Moncaster wrote: [snip] > >>> Auditing every packet is plausible near the sender and receiver, > >>> but not in the backbone. I don't believe we have agreement among > >>> ourselves what a receiver's uplink will do if their auditing shows > >>> "abuse" of ConEx marking: so I don't see what auditing at the > >>> sender's uplink can do and be confident it's the right thing. > >> > >> I agree, it seems hard to see how auditing something when you are > >> missing half the information is going to be hard. > > > > (I'm having trouble parsing that sentence.) > >I think we are hitting the issue of "what is=20 >audit?" If audit is taken to mean accounting for=20 >ConEx marks, then that can happen anywhere.=20 >However I was taking auditing to mean accounting=20 >for the balance of ConEx marks with actual=20 >congestion. That function can only work=20 >somewhere where you can see both the congestion=20 >and the ConEx marks. The only way you can=20 >achieve that at the sender side is by inspecting=20 >the ACKs on the return path (which may be impossible). [BB]: I want to take issue with 'the only way'.=20 There's at least one other very plausible=20 scenario. Assume by design there's one major=20 bottleneck on the upstream path from a sender=20 (e.g. a radio access network). Then a network=20 node at the congested point can see all the ConEx=20 and most of the loss (or ECN). It cannot know=20 what 'most' means, but bear with me... Imagine a sender is trying to cheat. This can=20 even be a really knowledgeable sender - a=20 disgruntled ex-employee of the network operator=20 who knows that the audit function is badly placed=20 - not near the receiver, but near the sender. Even if there might sometimes be another=20 bottleneck nearer the receiver on the path, when=20 this dishonest sender sees congestion feedback=20 (from loss or ECN), it cannot know which=20 bottleneck each congestion signal was from. So if this sender is trying to cheat, it will=20 sometimes understate ConEx markings with respect=20 to the first bottleneck alone. The audit at that=20 first bottleneck will detect persistent cheating,=20 so it knows the sender is suspect. An honest=20 sender might accidentally get ConEx marks wrong=20 occasionally, but not persistently badly like this. > >> There is a separate accounting mechanism where you can measure bulk > >> flows of congestion, but that has to be based on a belief in the > >> accuracy of the marking of the underlying individual flows. > > > > I don't see how that follows. > >Measuring the bulk is very easy, but if all the=20 >flows making up the bulk are understating their=20 >congestion then the bulk will be understated as=20 >well. Bob always had in mind a clever mechanism=20 >to do spot checking at any border to identify=20 >persistent under (or over) declaration, but I=20 >never entirely understood how it was meant to work. [BB]: The bulk auditing idea is primarily=20 designed to remove the motivation for networks to=20 launch attacks on /each other/ using ConEx. I=20 don't expect many networks would even think of=20 doing that, but unless you have a way of=20 detecting breaches of trust, you cannot rely on=20 that trust. You don't necessarily have to use the=20 mechanism; other networks just need to know that=20 there is feasible mechanism and you might be using it. > >>> Unless I misread draft-ietf-conex-concepts-uses, our principle > >>> use case is Informing Traffic Management. I have posted before that > >>> the most important feature of ConEx marking (IMHO) is informing > >>> any node along the way that the sender is knowingly sending packets > >>> despite having reason to doubt that congestion has cleared. > >>> > >>> Auditing does nothing to help here. The abusive thing to do is > >>> to _clear_ ConEx marks -- and auditing can't detect that. > >> > >> No. ConEx is about a balance of markings. To cheat you fail to send > >> forward into the network sufficient ConEx markings to cover the > >> congestion your flow is causing (or has caused). > > > > Not quite... an ISP can cheat by clearing marks which one sender > > placed in his outgoing traffic -- that is what I meant to refer to. > >OK, yes. That is a separate requirement for audit. [BB]: Just to ensure we make clear which sort of=20 abuse we're talking about at any one time, I=20 detect three different types of abuse being discussed here: a) The sender continuing to send despite=20 expecting that congestion has not cleared b) The sender understating ConEx markings relative to path congestion c) An ISP clearing the sender's ConEx markings a-type behaviour could describe normal TCP/IP or=20 UDP. It's only abuse if in excess. The idea of=20 ConEx is to give ISPs the info, so ISPs can draw=20 the line between normal and abuse, rather than=20 the IETF making this judgement call. (b) and (c) are about validity of ConEx=20 information, whereas (a) is about behaviour=20 measured by ConEx info. The idea is to prevent=20 b-type & c-type behaviour so that ConEx info is=20 reliable enough that ISPs can use it to make judgements about (a). b-type behaviour is intended to be addressed by audit. c-type behaviour can be addressed by e2e verification of ConEx info. We're not doing protocol work on (c) in the w-g,=20 but the info is in the protocol if we wanted to.=20 I can straight-off think of three possible protocols to address this: - The source could protect the integrity of the=20 DSOPT extension header with IPsec AH, so if an=20 ISP altered ConEx markings, AH integrity checks=20 would detect that something on-path had altered an immutable header. - We could add an e2e feedback field in TCP so=20 that the receiver can feed back the received=20 ConEx markings to the sender (re-re-feedback?).=20 Then the sender can check that an ISP hasn't changed what it sent. - The sender could log the packets it marks with=20 ConEx, and the receiver could occasionally send=20 back a log of the packets it receives with ConEx=20 markings for the sender to check (not sure what=20 protocol this would be added to). > >> So the function of auditing is to check that the two numbers > >> roughly match. > > > > (I note that Toby says "roughly match". Others seem to be assuming > > a much stricter match. I'm afraid we don't have a clear understanding > > here.) > >Clearly, given the min 1RTT delay between=20 >getting congestion info and responding to it,=20 >there can never be a completely accurate match.=20 >I did have numerous debates with Bob about this=20 >topic. Basically you run the risk of a user just=20 >terminating his flow rather than making up his losses. [BB]: That attack is dealt with. That's why I/we=20 decided that the sender has responsibility for=20 keeping ConEx info greater than or equal to=20 congestion, despite RTT delay. Then if the sender=20 runs up a 'loss' and jumps to a new flow, the end=20 of its last flow will have been discarded by the=20 audit function, so the sender won't have gained by this cheat. >You also have to be cautious that the actual=20 >process of dropping packets for audit doesn't=20 >simply distort the apparent congestion=20 >information (because the sender will respond by=20 >retransmitting and hopefully adding more ConEx marks) [BB]: We (in BT) established that's also not a=20 problem. The sender ought to match these audit=20 losses with the ConEx marks it didn't send in the=20 first place. If it doesn't, the audit node can=20 detect that, because it knows about the losses it introduced. > > > >> And yes, this is a very difficult problem to solve if you can't > >> assume ECN is being used. > > > > I absolutely agree with Toby here. [BB]: I also agree audit is hard without ECN -=20 but I believe it's not a lost cause (excuse the=20 pun). I started to agree with Matt when I=20 realised cases like that discussed earlier ('not=20 the only way' above) are common enough for ConEx without ECN to be useful. > > > >>> Auditing, to tell truth, may or may not prove useful after we > >>> have done enough experiments. IMHO, if it proves useful we'll find > >>> that it's useful when done statistically, rather than on every > >>> packet. > >> > >> I think this may point to the heart of the issue. Yes, you can sample > >> to do audit, but only if you assume a relatively high density of > >> markings. > > > > I don't follow why that is true. If auditing is not strict, sampling > > should work for a wide range of density; if auditing is strict, it > > will fail pretty much regardless of the density=85 > >OK, this comes down to the point below [BB]: Sampling isn't applicable if anyone who is=20 'caught' can just whitewash their reputation by=20 adopting a new clean identity. The problem is=20 that identity here is just a flow ID and new flow IDs can be created at= will. A dishonest transport can cheat in as many flows=20 as it can get away with, until sampling catches=20 one of its flows, which it just terminates and=20 starts another flow. E.g. a msbehaving receiver=20 could understate congestion feedback to a server.=20 When the receiver detects high loss, it assumes=20 it is being randomly audited, so it just=20 terminates that connection and opens a new one. "Reputation whitewashing" is easy when your=20 identity is as emphemeral as a flow ID and you're=20 the one who controls the end with the ephemeral ports. > >> If ConEx is a specific number carried in each packet then sparse > >> sampling may well give you enough to be able to achieve the aims of > >> audit. > > > > Carrying what I call "congestion-expected" as a multi-bit fraction > > is an interesting idea, in which I see potential benefits. I'd be > > happy to discuss it, but my impression is that we're not heading in > > that direction. > >That was certainly how I understood a re-ECN=20 >like scheme working=85 Te whole core of this=20 >argument (should you account for bytes or=20 >packets) has always been a major bone of=20 >contention between me and Bob. Not least because=20 >it can be impossible for a sender to comply (it=20 >is very easy to construct pathological sequences=20 >of packets where the sender is forced to either=20 >over or under declare if they are doing per-byte=20 >auditing). I think this is a case where the IETF=20 >view has to diverge from the researcher's view.=20 >In the IETF we have to make prosaic engineering=20 >decisions. Personally I would like ConEx to=20 >account on a per-packet basis, BUT with an=20 >allowance for it to be more accurate if an operator so wishes [BB]: that's my position too. Assuming "more accurate" means per-byte. I don't think this is disagreeing with the=20 wording in abstract-mech, or the proposed wording=20 in the tcp mods draft. If it is, pls say how. >(in other words MUST as a minimum account per=20 >packet, but MAY account per byte) Except I wouldn't state it in terms of what audit=20 must or may do, because the argument is about=20 what we say the transport should do (to be robust against what audit may= do). > >> Which brings me on to the aims of audit. To my mind there are two > >> possible aims. > >> 1) to guarantee that every single packet, flow, aggregation of traffic > >> in the network has accurately declared their congestion; or > >> 2) to act as a "speed camera" that catches a sufficiently high > >> proportion of infringements to ensure that senders don't risk > >> under-declaring their congestion. > > > > I don't see auditing as either of these; but that may be more a > > function of my tendency to think of auditing as gathering information, > > not enforcing disciplinary measures based on this information. > >Perhaps auditing is an unhelpful word to use. To=20 >my mind an audit implies an accountancy audit=20 >that tries to balance the books. I agree that=20 >carries no implication of policing or=20 >enforcement, but I think that a lot of this=20 >debate has assumed the two concepts are identical The critical issue is whether the audit function=20 is possible. Once it is, the action as a result of audit can be added. When audit is in a remote network from the=20 sender, the only action available seems to be to=20 'punish' the packets (e.g. drop) because it's too=20 complex in general to track down and 'punish' a=20 user that might be in another network. > > IMHO, "guaranteeing" much of anything isn't worth the effort over > > organizational boundaries. At significant expense, we could use > > cryptography to give arbitrarily high confidence to a particular > > "guarantee" having come from a particular entity, but without also > > signing the data "guaranteed", the effort is entirely wasted. > > > > (And processing all that cryptography in backbone routers seems > > a non-starter to me.) > >Agreed, this has to be a lightweight mechanism.=20 >All the guarantees have to come from the idea=20 >that operators have to have some level of trust=20 >among one another (or at least, the realisation=20 >that an operator found to have cheated at the=20 >expense of others runs risk of getting sat on heavily by the others), See point above - in a large distributed system,=20 trust can only be relied on if it would at least=20 be feasible to detect breaches of trust (in the=20 case of trust building, random sampling is highly appropriate). > >> My own view is that the second is more feasible in the real world, > >> although the first might well be more desirable. > > > > I at least partly agree here. However, my approach to thinking > > about such problems simply stops descending into details when I reach > > a feasibility blockage. > >And therein lies the lesson for ConEx. We HAVE=20 >to fix on a SIMPLE subset of ConEx that we can=20 >all agree on and that seems at least feasible in=20 >the real world. Arguments like the recent ones=20 >make ConEx appear to be still firmly stuck in=20 >the land of research (IRTF). Too many people (on=20 >all sides of all arguments) seem to want=20 >perfection and that is not sensible in the real=20 >world. That is just a recipe for ratholing=20 >ourselves to the point where the IESG declares our WG dysfunctional=85 See above. Bob >Toby > > > > > > -- > > John Leslie > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From tm444@hermes.cam.ac.uk Wed Dec 14 08:43: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 D535121F8C4C for ; Wed, 14 Dec 2011 08:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGL7KZ38M5jL for ; Wed, 14 Dec 2011 08:43:11 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0992221F8BBB for ; Wed, 14 Dec 2011 08:43:10 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:51910) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1RarvA-0001SZ-pm (Exim 4.72) (return-path ); Wed, 14 Dec 2011 16:43:08 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster In-Reply-To: <201112132012.pBDKCokX014681@bagheera.jungle.bt.co.uk> Date: Wed, 14 Dec 2011 16:43:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6342D66E-6525-49D4-9DD9-3713230F2303@cl.cam.ac.uk> References: <201111201956.pAKJuJSQ007421@bagheera.jungle.bt.co.uk> <20111120214012.GE22465@verdi> <201111202327.pAKNRJPT008060@bagheera.jungle.bt.co.uk> <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> <20111202232051.GH31463@verdi> <20111205230153.GC39149@verdi> <9BD81879-81A2-4EF0-A60B-F541D0BA418B@cl.cam.ac.uk> <201112132012.pBDKCokX014681@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1251.1) Sender: "T. Moncaster" Cc: "T. Moncaster" , ConEx IETF list Subject: Re: [conex] byte vs packet counting 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, 14 Dec 2011 16:43:12 -0000 Hi Bob, On 13 Dec 2011, at 20:12, Bob Briscoe wrote: > Toby, >=20 > Catching up after been away for a week... > Inline, and I've snipped everything I agree with=85 OK >=20 > At 09:50 06/12/2011, Toby Moncaster wrote: >> On 5 Dec 2011, at 23:01, John Leslie wrote: >> > T. Moncaster wrote: >=20 > [snip] >=20 >> >>> Auditing every packet is plausible near the sender and receiver, >> >>> but not in the backbone. I don't believe we have agreement among >> >>> ourselves what a receiver's uplink will do if their auditing = shows >> >>> "abuse" of ConEx marking: so I don't see what auditing at the >> >>> sender's uplink can do and be confident it's the right thing. >> >> >> >> I agree, it seems hard to see how auditing something when you are >> >> missing half the information is going to be hard. >> > >> > (I'm having trouble parsing that sentence.) >>=20 >> I think we are hitting the issue of "what is audit?" If audit is = taken to mean accounting for ConEx marks, then that can happen anywhere. = However I was taking auditing to mean accounting for the balance of = ConEx marks with actual congestion. That function can only work = somewhere where you can see both the congestion and the ConEx marks. The = only way you can achieve that at the sender side is by inspecting the = ACKs on the return path (which may be impossible). >=20 > [BB]: I want to take issue with 'the only way'. There's at least one = other very plausible scenario. Assume by design there's one major = bottleneck on the upstream path from a sender (e.g. a radio access = network). Then a network node at the congested point can see all the = ConEx and most of the loss (or ECN). It cannot know what 'most' means, = but bear with me... >=20 > Imagine a sender is trying to cheat. This can even be a really = knowledgeable sender - a disgruntled ex-employee of the network operator = who knows that the audit function is badly placed - not near the = receiver, but near the sender. >=20 > Even if there might sometimes be another bottleneck nearer the = receiver on the path, when this dishonest sender sees congestion = feedback (from loss or ECN), it cannot know which bottleneck each = congestion signal was from. >=20 > So if this sender is trying to cheat, it will sometimes understate = ConEx markings with respect to the first bottleneck alone. The audit at = that first bottleneck will detect persistent cheating, so it knows the = sender is suspect. An honest sender might accidentally get ConEx marks = wrong occasionally, but not persistently badly like this. It would be interesting to get a feel for how common this scenario is. I = think what you are saying is that the audit function doesn't have to be = perfect, it just needs to be reasonably likely of catching persistent = under-declaration of congestion? >=20 >=20 >> >> There is a separate accounting mechanism where you can measure = bulk >> >> flows of congestion, but that has to be based on a belief in the >> >> accuracy of the marking of the underlying individual flows. >> > >> > I don't see how that follows. >>=20 >> Measuring the bulk is very easy, but if all the flows making up the = bulk are understating their congestion then the bulk will be understated = as well. Bob always had in mind a clever mechanism to do spot checking = at any border to identify persistent under (or over) declaration, but I = never entirely understood how it was meant to work. >=20 > [BB]: The bulk auditing idea is primarily designed to remove the = motivation for networks to launch attacks on /each other/ using ConEx. I = don't expect many networks would even think of doing that, but unless = you have a way of detecting breaches of trust, you cannot rely on that = trust. You don't necessarily have to use the mechanism; other networks = just need to know that there is feasible mechanism and you might be = using it. A key point to get across. >=20 >> >>> Unless I misread draft-ietf-conex-concepts-uses, our principle >> >>> use case is Informing Traffic Management. I have posted before = that >> >>> the most important feature of ConEx marking (IMHO) is informing >> >>> any node along the way that the sender is knowingly sending = packets >> >>> despite having reason to doubt that congestion has cleared. >> >>> >> >>> Auditing does nothing to help here. The abusive thing to do is >> >>> to _clear_ ConEx marks -- and auditing can't detect that. >> >> >> >> No. ConEx is about a balance of markings. To cheat you fail to = send >> >> forward into the network sufficient ConEx markings to cover the >> >> congestion your flow is causing (or has caused). >> > >> > Not quite... an ISP can cheat by clearing marks which one sender >> > placed in his outgoing traffic -- that is what I meant to refer to. >>=20 >> OK, yes. That is a separate requirement for audit. >=20 > [BB]: Just to ensure we make clear which sort of abuse we're talking = about at any one time, I detect three different types of abuse being = discussed here: > a) The sender continuing to send despite expecting that congestion has = not cleared > b) The sender understating ConEx markings relative to path congestion > c) An ISP clearing the sender's ConEx markings >=20 > a-type behaviour could describe normal TCP/IP or UDP. It's only abuse = if in excess. The idea of ConEx is to give ISPs the info, so ISPs can = draw the line between normal and abuse, rather than the IETF making this = judgement call. >=20 > (b) and (c) are about validity of ConEx information, whereas (a) is = about behaviour measured by ConEx info. The idea is to prevent b-type & = c-type behaviour so that ConEx info is reliable enough that ISPs can use = it to make judgements about (a). >=20 > b-type behaviour is intended to be addressed by audit. >=20 > c-type behaviour can be addressed by e2e verification of ConEx info. I think this is a really good and clear description of the ways to = distort ConEx info. I would like to see something like this as a = stand-alone informational draft (at least for now) so we have it = captured somewhere and can refer back to it as and when needed. >=20 > We're not doing protocol work on (c) in the w-g, but the info is in = the protocol if we wanted to. I can straight-off think of three possible = protocols to address this: > - The source could protect the integrity of the DSOPT extension header = with IPsec AH, so if an ISP altered ConEx markings, AH integrity checks = would detect that something on-path had altered an immutable header. > - We could add an e2e feedback field in TCP so that the receiver can = feed back the received ConEx markings to the sender (re-re-feedback?). = Then the sender can check that an ISP hasn't changed what it sent. > - The sender could log the packets it marks with ConEx, and the = receiver could occasionally send back a log of the packets it receives = with ConEx markings for the sender to check (not sure what protocol this = would be added to). I'm afraid I'm being lazy for now and not evaluating these suggestions. >=20 >> >> So the function of auditing is to check that the two numbers >> >> roughly match. >> > >> > (I note that Toby says "roughly match". Others seem to be = assuming >> > a much stricter match. I'm afraid we don't have a clear = understanding >> > here.) >>=20 >> Clearly, given the min 1RTT delay between getting congestion info and = responding to it, there can never be a completely accurate match. I did = have numerous debates with Bob about this topic. Basically you run the = risk of a user just terminating his flow rather than making up his = losses. >=20 > [BB]: That attack is dealt with. That's why I/we decided that the = sender has responsibility for keeping ConEx info greater than or equal = to congestion, despite RTT delay. Then if the sender runs up a 'loss' = and jumps to a new flow, the end of its last flow will have been = discarded by the audit function, so the sender won't have gained by this = cheat. I think this may be one of the things people haven't understood. Namely, = we need any sender to start by assuming they will cause a little bit of = congestion and paying for that up-front. >=20 >> You also have to be cautious that the actual process of dropping = packets for audit doesn't simply distort the apparent congestion = information (because the sender will respond by retransmitting and = hopefully adding more ConEx marks) >=20 > [BB]: We (in BT) established that's also not a problem. The sender = ought to match these audit losses with the ConEx marks it didn't send in = the first place. If it doesn't, the audit node can detect that, because = it knows about the losses it introduced. The only drawback then is that the aggregate over the path is possibly = distorted (as in, some of the stated congestion isn't actual congestion) = which may have an impact on some future ConEx use cases. >=20 >> > >> >> And yes, this is a very difficult problem to solve if you can't >> >> assume ECN is being used. >> > >> > I absolutely agree with Toby here. >=20 > [BB]: I also agree audit is hard without ECN - but I believe it's not = a lost cause (excuse the pun). I started to agree with Matt when I = realised cases like that discussed earlier ('not the only way' above) = are common enough for ConEx without ECN to be useful. I never said it was impossible, it's just that ECN does give you a lot = more information >=20 >> > >> >>> Auditing, to tell truth, may or may not prove useful after we >> >>> have done enough experiments. IMHO, if it proves useful we'll = find >> >>> that it's useful when done statistically, rather than on every >> >>> packet. >> >> >> >> I think this may point to the heart of the issue. Yes, you can = sample >> >> to do audit, but only if you assume a relatively high density of >> >> markings. >> > >> > I don't follow why that is true. If auditing is not strict, = sampling >> > should work for a wide range of density; if auditing is strict, it >> > will fail pretty much regardless of the density=85 >>=20 >> OK, this comes down to the point below >=20 > [BB]: Sampling isn't applicable if anyone who is 'caught' can just = whitewash their reputation by adopting a new clean identity. The problem = is that identity here is just a flow ID and new flow IDs can be created = at will. >=20 > A dishonest transport can cheat in as many flows as it can get away = with, until sampling catches one of its flows, which it just terminates = and starts another flow. E.g. a msbehaving receiver could understate = congestion feedback to a server. When the receiver detects high loss, it = assumes it is being randomly audited, so it just terminates that = connection and opens a new one. >=20 > "Reputation whitewashing" is easy when your identity is as emphemeral = as a flow ID and you're the one who controls the end with the ephemeral = ports. So what you are arguing is that speed camera-style auditing is not = sensible because in the Internet you can change your car registration at = will with near zero cost, and there is no external mechanism (licensing = authority) that can retrospectively apply a sanction to you? (sorry for = the convoluted simile) >=20 >> >> If ConEx is a specific number carried in each packet then sparse >> >> sampling may well give you enough to be able to achieve the aims = of >> >> audit. >> > >> > Carrying what I call "congestion-expected" as a multi-bit = fraction >> > is an interesting idea, in which I see potential benefits. I'd be >> > happy to discuss it, but my impression is that we're not heading in >> > that direction. >>=20 >> That was certainly how I understood a re-ECN like scheme working=85 = Te whole core of this argument (should you account for bytes or packets) = has always been a major bone of contention between me and Bob. Not least = because it can be impossible for a sender to comply (it is very easy to = construct pathological sequences of packets where the sender is forced = to either over or under declare if they are doing per-byte auditing). I = think this is a case where the IETF view has to diverge from the = researcher's view. In the IETF we have to make prosaic engineering = decisions. Personally I would like ConEx to account on a per-packet = basis, BUT with an allowance for it to be more accurate if an operator = so wishes >=20 > [BB]: that's my position too. > Assuming "more accurate" means per-byte. That was my implication, yes ;) >=20 > I don't think this is disagreeing with the wording in abstract-mech, = or the proposed wording in the tcp mods draft. If it is, pls say how. >=20 >> (in other words MUST as a minimum account per packet, but MAY account = per byte) >=20 > Except I wouldn't state it in terms of what audit must or may do, = because the argument is about what we say the transport should do (to be = robust against what audit may do). OK, but we probably need to have some minimal black-box definition of = what an audit function needs to do to be "compliant" >=20 >> >> Which brings me on to the aims of audit. To my mind there are two >> >> possible aims. >> >> 1) to guarantee that every single packet, flow, aggregation of = traffic >> >> in the network has accurately declared their congestion; or >> >> 2) to act as a "speed camera" that catches a sufficiently high >> >> proportion of infringements to ensure that senders don't risk >> >> under-declaring their congestion. >> > >> > I don't see auditing as either of these; but that may be more a >> > function of my tendency to think of auditing as gathering = information, >> > not enforcing disciplinary measures based on this information. >>=20 >> Perhaps auditing is an unhelpful word to use. To my mind an audit = implies an accountancy audit that tries to balance the books. I agree = that carries no implication of policing or enforcement, but I think that = a lot of this debate has assumed the two concepts are identical >=20 > The critical issue is whether the audit function is possible. Once it = is, the action as a result of audit can be added. I agree we clearly have two functions - audit and reaction to audit. = Audit in and of itself simply says there is an issue. >=20 > When audit is in a remote network from the sender, the only action = available seems to be to 'punish' the packets (e.g. drop) because it's = too complex in general to track down and 'punish' a user that might be = in another network. Agreed >=20 >> > IMHO, "guaranteeing" much of anything isn't worth the effort over >> > organizational boundaries. At significant expense, we could use >> > cryptography to give arbitrarily high confidence to a particular >> > "guarantee" having come from a particular entity, but without also >> > signing the data "guaranteed", the effort is entirely wasted. >> > >> > (And processing all that cryptography in backbone routers seems >> > a non-starter to me.) >>=20 >> Agreed, this has to be a lightweight mechanism. All the guarantees = have to come from the idea that operators have to have some level of = trust among one another (or at least, the realisation that an operator = found to have cheated at the expense of others runs risk of getting sat = on heavily by the others), >=20 > See point above - in a large distributed system, trust can only be = relied on if it would at least be feasible to detect breaches of trust = (in the case of trust building, random sampling is highly appropriate). Absolutely. Among operators you can genuinely rely on the speed camera = approach to audit - the risk of getting caught may be low (but has to be = finite) but the harm to your reputation makes the risk unjustifiable=20 >=20 >> >> My own view is that the second is more feasible in the real world, >> >> although the first might well be more desirable. >> > >> > I at least partly agree here. However, my approach to thinking >> > about such problems simply stops descending into details when I = reach >> > a feasibility blockage. >>=20 >> And therein lies the lesson for ConEx. We HAVE to fix on a SIMPLE = subset of ConEx that we can all agree on and that seems at least = feasible in the real world. Arguments like the recent ones make ConEx = appear to be still firmly stuck in the land of research (IRTF). Too many = people (on all sides of all arguments) seem to want perfection and that = is not sensible in the real world. That is just a recipe for ratholing = ourselves to the point where the IESG declares our WG dysfunctional=85 >=20 > See above. I actually think the disagreements among us are quite small and are = (generally) semantic. The problem is that they look much bigger to any = outsider.=20 Toby >=20 >=20 > Bob >=20 >=20 >> Toby >>=20 >>=20 >> > >> > -- >> > John Leslie >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From john@jlc.net Thu Dec 15 12:07: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 2D68021F8A96 for ; Thu, 15 Dec 2011 12:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR2mjN+-y2WF for ; Thu, 15 Dec 2011 12:07:01 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 63EE821F8A35 for ; Thu, 15 Dec 2011 12:07:01 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5637A33C20; Thu, 15 Dec 2011 15:07:01 -0500 (EST) Date: Thu, 15 Dec 2011 15:07:01 -0500 From: John Leslie To: Toby Moncaster Message-ID: <20111215200701.GA26608@verdi> References: <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> <20111202232051.GH31463@verdi> <20111205230153.GC39149@verdi> <9BD81879-81A2-4EF0-A60B-F541D0BA418B@cl.cam.ac.uk> <201112132012.pBDKCokX014681@bagheera.jungle.bt.co.uk> <6342D66E-6525-49D4-9DD9-3713230F2303@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6342D66E-6525-49D4-9DD9-3713230F2303@cl.cam.ac.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] byte vs packet counting 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, 15 Dec 2011 20:07:02 -0000 Toby and Bob raise a number of points I will follow-up in separate threads, but one point deserves to be in this thread. Toby Moncaster wrote: > On 13 Dec 2011, at 20:12, Bob Briscoe wrote: >> At 09:50 06/12/2011, Toby Moncaster wrote: >> >>> The whole core of this argument (should you account for bytes or >>> packets) has always been a major bone of contention between me and >>> Bob. Not least because it can be impossible for a sender to comply >>> (it is very easy to construct pathological sequences of packets >>> where the sender is forced to either over or under declare if they >>> are doing per-byte auditing). I think this is a case where the >>> IETF view has to diverge from the researcher's view. In the IETF >>> we have to make prosaic engineering decisions. Personally I would >>> like ConEx to account on a per-packet basis, BUT with an allowance >>> for it to be more accurate if an operator so wishes >> >> [BB]: that's my position too. >> Assuming "more accurate" means per-byte. > > That was my implication, yes ;) I must dissent on calling per-byte "more accurate" than per-packet when the number of packets is clearly defined and the number of bytes is inferred (and in at least some cases, inaccurate). Bob seems immovable in his belief that per-byte accounting is "more correct", despite a number of posts showing cases where the per-packet overhead dominates. I feel just as immovable in claiming that neither will _always_ dominate. I prefer counting packets because it's simpler; I'm willing to count bytes if a clear benefit is demonstrated during Experimental phase. Thus it's time for a specific proposal in compromise. I propose that the ConEx Destination Option carry a 16-bit field for byte-count, and this field be optional -- both for the sender to fill or not, and for any node along the path to check or not. Thus, during the Experimental phase, any sender could set it and see what changes (if anything); and any node along the path could gather data on actual variations in this number and draw conclusions about potential benefits of its use. IMHO, unless senders voluntarily set it and at least some nodes voluntarily use it, there _can_be_ no benefit. But I'm willing to leave the field in place against a possible future use. (I hope to live long enough to see 4k packets become common in the wild; this could expose a greater benefit from considering bytes per packet.) I'm not willing to "go along" with Bob on _inferring_ a byte count and calling that more accurate; but I'm willing to accept an explicit byte count with exact details of how the auditing function may use it left for future work. -- John Leslie From john@jlc.net Thu Dec 15 13:18: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 BD06F21F8678 for ; Thu, 15 Dec 2011 13:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.492 X-Spam-Level: X-Spam-Status: No, score=-107.492 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAqOg+RWTrec for ; Thu, 15 Dec 2011 13:18:02 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 330F621F85FF for ; Thu, 15 Dec 2011 13:18:02 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4727433C20; Thu, 15 Dec 2011 16:18:01 -0500 (EST) Date: Thu, 15 Dec 2011 16:18:01 -0500 From: John Leslie To: Toby Moncaster Message-ID: <20111215211801.GB26608@verdi> References: <20111121203356.GG22465@verdi> <201111212314.pALNEhvZ013554@bagheera.jungle.bt.co.uk> <20111122001928.GH22465@verdi> <82AB329A76E2484D934BBCA77E9F524924B97E81@Polydeuces.office.hd> <20111202232051.GH31463@verdi> <20111205230153.GC39149@verdi> <9BD81879-81A2-4EF0-A60B-F541D0BA418B@cl.cam.ac.uk> <201112132012.pBDKCokX014681@bagheera.jungle.bt.co.uk> <6342D66E-6525-49D4-9DD9-3713230F2303@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6342D66E-6525-49D4-9DD9-3713230F2303@cl.cam.ac.uk> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: [conex] Catching "Cheaters" 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, 15 Dec 2011 21:18:03 -0000 This is still rather longish, but I think it holds together enough... Toby Moncaster wrote: > On 13 Dec 2011, at 20:12, Bob Briscoe wrote: >> >> Imagine a sender is trying to cheat. This can even be a really >> knowledgeable sender - a disgruntled ex-employee of the network >> operator who knows that the audit function is badly placed - not >> near the receiver, but near the sender. >> >> Even if there might sometimes be another bottleneck nearer the >> receiver on the path, when this dishonest sender sees congestion >> feedback (from loss or ECN), it cannot know which bottleneck each >> congestion signal was from. The most likely bottleneck near the sender is the uplink from the customer of the ADSL or Cable modem. >> So if this sender is trying to cheat, it will sometimes understate >> ConEx markings with respect to the first bottleneck alone. Assuming Bob means the cheater _is_ the sender, it can still have a pretty good picture of the congestion rate in its upstream link. >> The audit at that first bottleneck will detect persistent cheating, >> so it knows the sender is suspect... Understand that ConEx credit marks can get lost: the audit function can't expect to see _every_ ConEx mark. Even assuming that the cheating is sufficiently flagrant, I don't see how we could specify what the audit function must do... >> [BB]: Just to ensure we make clear which sort of abuse we're talking >> about at any one time, I detect three different types of abuse being >> discussed here: >> a) The sender continuing to send despite expecting that congestion >> has not cleared >> b) The sender understating ConEx markings relative to path congestion >> c) An ISP clearing the sender's ConEx markings >> >> a-type behaviour could describe normal TCP/IP or UDP. It's only abuse >> if in excess. The idea of ConEx is to give ISPs the info, so ISPs >> can draw the line between normal and abuse, rather than the IETF >> making this judgement call. I agree the IETF shouldn't make that judgment call. >> (b) and (c) are about validity of ConEx information, whereas (a) is >> about behaviour measured by ConEx info. The idea is to prevent >> b-type & c-type behaviour so that ConEx info is reliable enough >> that ISPs can use it to make judgements about (a). >> >> b-type behaviour is intended to be addressed by audit. >> >> c-type behaviour can be addressed by e2e verification of ConEx info. > > I think this is a really good and clear description of the ways to > distort ConEx info. I would like to see something like this as a > stand-alone informational draft (at least for now) so we have it > captured somewhere and can refer back to it as and when needed. I'd love to see Toby work on such an I-D. I'd be willing to help. >> We're not doing protocol work on (c) in the w-g, but the info is >> in the protocol if we wanted to. I can straight-off think of three >> possible protocols to address this: >> - The source could protect the integrity of the DSOPT extension >> header with IPsec AH, so if an ISP altered ConEx markings, AH >> integrity checks would detect that something on-path had altered >> an immutable header. >> - We could add an e2e feedback field in TCP so that the receiver >> can feed back the received ConEx markings to the sender >> (re-re-feedback?). Then the sender can check that an ISP hasn't >> changed what it sent. >> - The sender could log the packets it marks with ConEx, and the >> receiver could occasionally send back a log of the packets it >> receives with ConEx markings for the sender to check (not sure >> what protocol this would be added to). I don't believe the IPsec case is worth pursuing. The second and third might prove worthwhile, but at this point I don't see what we could specify which would help. >> Toby Moncaster wrote: >> >>> Clearly, given the min 1RTT delay between getting congestion info >>> and responding to it, there can never be a completely accurate >>> match. I did have numerous debates with Bob about this topic. >>> Basically you run the risk of a user just terminating his flow >>> rather than making up his losses. >> >> [BB]: That attack is dealt with. That's why I/we decided that the >> sender has responsibility for keeping ConEx info greater than or >> equal to congestion, despite RTT delay. Then if the sender runs up >> a 'loss' and jumps to a new flow, the end of its last flow will >> have been discarded by the audit function, so the sender won't have >> gained by this cheat. > > I think this may be one of the things people haven't understood. > Namely, we need any sender to start by assuming they will cause a > little bit of congestion and paying for that up-front. Worth including in that I-D I hope Toby will write... Nonetheless, I don't think we should make any requirement for ConEx credits for _every_ packet in flight (which I have seen proposed). While, indeed, 100% loss is possible, that's not a case worth a lot of worry -- it's essentially a dead path, and optimizing a dead path seems silly. Nor do I think we should _define_ a likely loss rate for packets in flight. That deserves to be a judgment call for each sender. The question is, if the sender guesses low, what should happen? It doesn't bother me if an audit policer drops some more packets in that case; nor does it bother me if it doesn't. It's not worth the effort to me to keep that much state about connections originating at some other ISP. But I'm happy to see a statement that senders SHOULD estimate a likely loss rate for packets in flight. >>> You also have to be cautious that the actual process of dropping >>> packets for audit doesn't simply distort the apparent congestion >>> information (because the sender will respond by retransmitting >>> and hopefully adding more ConEx marks) >> >> [BB]: We (in BT) established that's also not a problem. The sender >> ought to match these audit losses with the ConEx marks it didn't >> send in the first place. If it doesn't, the audit node can detect >> that, because it knows about the losses it introduced. (Assuming a single audit node...) > The only drawback then is that the aggregate over the path is possibly > distorted (as in, some of the stated congestion isn't actual congestion) > which may have an impact on some future ConEx use cases. IMHO, we're going to have to live with cases of overstated congestion; and it isn't worth the effort of trying to stop them. >> [BB]: Sampling isn't applicable if anyone who is 'caught' can just >> whitewash their reputation by adopting a new clean identity. The >> problem is that identity here is just a flow ID and new flow IDs >> can be created at will. Actually, I think we still waving hands wildly on what constitutes a "flow" as we get farther from the sender. The IPv6 "flow ID" field is almost never used, and proposals I've seen to get it used more seem a bit buggy... >> A dishonest transport can cheat in as many flows as it can get away >> with, until sampling catches one of its flows, which it just >> terminates and starts another flow. E.g. a misbehaving receiver >> could understate congestion feedback to a server. When the receiver >> detects high loss, it assumes it is being randomly audited, so it >> just terminates that connection and opens a new one. In truth, just the escalation of state information to be kept would be a problem. (And there probably isn't even a need to terminate a "connection".) IMHO, keeping per-flow state at all far from the sender (or the receiver, if the receiver is being held responsible for congestion) is a non-starter: I just don't see how we can limit the state information to a manageable level. OTOH, the overall amount of congestion coming into my AS from each peer is a concern worthy of keeping per-AS state: thus I expect per-AS state to be kept and acted upon. For purposes of per-AS state, it doesn't help to argue whether it's honest or dishonest: either way, it threatens to congest _all_ my traffic to the particular destination. >> "Reputation whitewashing" is easy when your identity is as emphemeral >> as a flow ID and you're the one who controls the end with the >> ephemeral ports. Agreed. But reputation of my peer AS's can't be whitewashed. > So what you are arguing is that speed camera-style auditing is not > sensible because in the Internet you can change your car registration > at will with near zero cost, and there is no external mechanism > (licensing authority) that can retrospectively apply a sanction to > you? (sorry for the convoluted simile) I'll argue that one: speed-camera is not particularly sensible for blaming individual _flows_ because we have no protection of any of the available methods to identify the flows to blame. >> When audit is in a remote network from the sender, the only action >> available seems to be to 'punish' the packets (e.g. drop) because >> it's too complex in general to track down and 'punish' a user that >> might be in another network. > > Agreed Likewise, agreed -- with the additional note that matching the drops to the actual flow will not always be possible. Nonetheless, I would agree it's reasonable to drop packets that _are_ marked ConEx-aware but appear to be part of a flow which has not built up sufficient credit -- in those cases where we have reason to believe _some_ packets to that destination will have to be dropped anyway. I don't honestly see much benefit from "punishing" a failure to estimate enough congestion unless we have evidence that packet drop is inevitable (somewhere) anyway. (If nothing else, that would be a DoS invitation.) >> See point above - in a large distributed system, trust can only be >> relied on if it would at least be feasible to detect breaches of >> trust (in the case of trust building, random sampling is highly >> appropriate). > > Absolutely. Among operators you can genuinely rely on the speed camera > approach to audit - the risk of getting caught may be low (but has to > be finite) but the harm to your reputation makes the risk unjustifiable Exactly! >>> And therein lies the lesson for ConEx. We HAVE to fix on a SIMPLE >>> subset of ConEx that we can all agree on and that seems at least >>> feasible in the real world. Arguments like the recent ones make >>> ConEx appear to be still firmly stuck in the land of research >>> (IRTF). Too many people (on all sides of all arguments) seem to >>> want perfection and that is not sensible in the real world. >>> That is just a recipe for ratholing ourselves to the point where >>> the IESG declares our WG dysfunctional? >> >> See above. > > I actually think the disagreements among us are quite small and are > (generally) semantic. The problem is that they look much bigger to > any outsider. IMHO our disagreements, whether small or not, are often fundamental; and our intransigence is what makes the problems appear so big. To whatever extent we are willing to let go of our insistence upon any particular solution, I think folks are happy to see this work continue; but where we hang on too tightly to one particular "solution", we start to look "dysfunctional". :^( -- John Leslie From philip.eardley@bt.com Mon Dec 19 00:29: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 2C3EE21F8A4E for ; Mon, 19 Dec 2011 00:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.14 X-Spam-Level: X-Spam-Status: No, score=-101.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvIJqxafK+zd for ; Mon, 19 Dec 2011 00:29:33 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3973E21F891D for ; Mon, 19 Dec 2011 00:29:32 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Dec 2011 08:29:31 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.81]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 19 Dec 2011 08:29:31 +0000 From: To: , Date: Mon, 19 Dec 2011 08:29:27 +0000 Thread-Topic: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt Thread-Index: Acyky94iyEuWgru7SSWI6RDkXkj9swZXBWXQ Message-ID: <9510D26531EF184D9017DF24659BB87F3311080B41@EMV65-UKRD.domain1.systemhost.net> References: <4EC4690C.2060707@it.uc3m.es> In-Reply-To: <4EC4690C.2060707@it.uc3m.es> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.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, 19 Dec 2011 08:29:34 -0000 Here are some late comments on the draft, sorry they are late/ Best wishes Phil Doc is good, seems ready to me. Minor comments S2.2 "congestion is a property of a link or a path" - seems in tension with= the statement at the end of S2.1 "[this doc doesn't define] congestion as = a condition or state"? S2.3 para 1, "measures" -> "is" (twice) - think this would be better as you= 're defining what rest-of-path & upstream congestion are Last para of S3, p10. There's a bit of a jump from the penultimate sentence= about flat rate pricing to the last sentence about conex. Needs some linki= ng S4, Enabling more efficient capacity provisioning - this para is hard to fo= llow, it twists around a bit. Also, change title to Enabling more efficient= usage of capacity? I think it may be simpler to split into a use case whic= h is user-focussed (about scavenger) and another which is operator-focussed= . S5 para 2 "strong incentive to tell the network .. data" -> "some incentive= to deploy conex" Para 3, Specifies -> proposes (so you don't have to wait for the conex-tcp = draft) Philip Eardley=A0=A0=A0 Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of m= arcelo bagnulo braun Sent: 17 November 2011 01:53 To: 'ConEx IETF list' Subject: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt. (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt) Please review the document and send comments before the 5th december. Thanks, marcelo _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From philip.eardley@bt.com Mon Dec 19 00:39:25 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35CE21F8B20 for ; Mon, 19 Dec 2011 00:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.863 X-Spam-Level: X-Spam-Status: No, score=-100.863 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJX1L0rFmwlQ for ; Mon, 19 Dec 2011 00:39:24 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 600C621F8A55 for ; Mon, 19 Dec 2011 00:39:24 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Dec 2011 08:39:23 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.81]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 19 Dec 2011 08:39:23 +0000 From: To: , Date: Mon, 19 Dec 2011 08:39:22 +0000 Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-03.txt Thread-Index: Acyky5QCSZmQtZzDS8qvqorP4jw6VAZXfI2w Message-ID: <9510D26531EF184D9017DF24659BB87F3311080B68@EMV65-UKRD.domain1.systemhost.net> References: <4EC468D5.5040009@it.uc3m.es> In-Reply-To: <4EC468D5.5040009@it.uc3m.es> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-03.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, 19 Dec 2011 08:39:25 -0000 Here are some comments, sorry they are late Best wishes Phil Basically seems ready and to do the job. S3.2 and S4.5.3 need a bit of work= I think. I don't think you'll get away with the minimalist S7 Security con= siderations. Otherwise minor comments. S1 "One of the required functions ..." is it "required"? Simply: "A transport = protocol controls congestion in the network." Para 3 sentence 1 is awkward, "This document proposes..." - suggest splitti= ng the sentence in two and re-phrasing=20 1.1 Terminology. Add "ConEx Signal - a packet sent by a ConEx-capable transport. It has one = of the following values... "aka" should be deleted S2 Requirements I think the section could have a couple of lines of intro. "Network device= s read the ConEx Signal, which indicates the end-to-end congestion, and may= act based on its measurements. In order to act reasonably, the ConEx Signa= l needs to be accurate and timely. In order to discourage the sender from s= ending a false ConEx Signal, it needs to be auditable; the basic audit tech= nique is to count and compare the ConEx Signal and the actual congestion." "any of these requirements" -> "a requirement" p7 bullet 1, "should never" -> SHOULD NOT the sub-bullets seem too detailed at this point S3=20 I wondered if the intro here should be (also) in S1.=20 "most important" - delete Penultimate para, "experimental conex encoding chosen for IPv6 [i-d] had to= make" -> "encoding [i-d] makes" (otherwise this doc will have to wait for = the encoding i-d). Last sentence re-phrase: "If experiments reveal partic= ular issues with the encoding, then this document will still serve as a ref= erence point" S3.1 You could start with some words how this relates to the ConEx Signal codepo= ints, ie naive is Conex-marked & conex-not-marked. S3.3 should be S3.2. the reader expects to read about the abstract encoding= immediately after the naive encoding.=20 Para 2, bytes vs packets - might be better to deal with is separately, thin= k it would be better than hiding within codepoint discussion S3.3.2 - could be phrased better S3.2 - thought this needed improvement. Suggest re-writing this without tal= king about re-ECN, and then having an Appendix that's re-ecn specific. The = first para is almost enough. You could add some capitals: the encoding SHOULD support ECN, meaning (1) c= ongestion is signalled with ECN, (2) the transport sender and receiver are = ECN-enabled. "re-ecn specification" -> draft. "central theme...", "takes a step back..."= not relevant here. "perfectly" is bold. S4 "natural ultimate" -> "the" S4.2 insert "for example" before [I-D.conex-tcp-mods] (otherwise you'll hav= e to wait for it to be an rfc]" "because it known that conex without ecn is harder to audit" - known -> bel= ieved. Add a reference. Is it possible to add a hint of the explanation? Do= es it affect the auditing hardness whether the receiver is modified or not? Thought S4.2 could end with "harder to audit" - the rest didn't seem releva= nt here (move to Incremental deployment section? S4.4 add "for example" in line 2 S4.4.2 "Audit SHOULD quickly detect and sanction dishonest flows, preferabl= y at the first dishonest packet" - preferably -> ideally S4.5.3. Congestion policers - think this needs some improvement. Perhaps so= me words could be copied from the use cases doc. Start by saying its purpos= e, something like "A congestion policer limits the congestion. It reads the ConEx Signals in= order to measure the amount of congestion that the traffic causes somewher= e downstream. If, for example, the congestion-bit-rate exceeds some configu= red level, then it takes action to limit the amount of conex traffic by dro= pping, delaying or downgrading traffic. Typically the congestion policer op= erates separately for each user. It can be implemented by a simple token bu= cket..." S5 "in every possible respect" is bold?=20 Sources -> senders. Conex packet markings -> ConEx Signals P18 middle para "If necessary, endpoints would be able to detect if a netwo= rk were removing ConEx signals" - would be able to -> SHOULD? were -> is Next para - does the use cases draft still include discussion of deployment= incentives? S7 - I guess this needs bulking up Codepoints or code points ConEx Signal - capitalise consistently Philip Eardley=A0=A0=A0 Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of m= arcelo bagnulo braun Sent: 17 November 2011 01:52 To: 'ConEx IETF list' Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-03.txt This note issues the WGLC for draft-ietf-conex-abstract-mech-03.txt. (http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt) Please review the document and send comments before the 5th december. Thanks, marcelo _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Wed Dec 21 02:38: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 AE46921F853B for ; Wed, 21 Dec 2011 02:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrhXwHfF5JQW for ; Wed, 21 Dec 2011 02:38:28 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 242B221F8531 for ; Wed, 21 Dec 2011 02:38:27 -0800 (PST) X-uc3m-safe: yes Received: from r190-132-123-68.dialup.mobile.ancel.net.uy (r190-132-123-68.dialup.mobile.ancel.net.uy [190.132.123.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 46271BE6A70 for ; Wed, 21 Dec 2011 11:38:24 +0100 (CET) Message-ID: <4EF1B719.3050601@it.uc3m.es> Date: Wed, 21 Dec 2011 11:38:17 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 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-18596.006 Subject: [conex] minutes posted 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, 21 Dec 2011 10:38:28 -0000 Hi, I have posted the minutes. http://www.ietf.org/proceedings/82/minutes/conex.txt send me comments if you have any. Thanks to Andrew for taking them, and i apologize for the delay in psting them. Regards, marcelo From acooper@cdt.org Sat Dec 31 06:28: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 A6D2121F845F for ; Sat, 31 Dec 2011 06:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.824 X-Spam-Level: X-Spam-Status: No, score=-101.824 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBAtOgSAlD6r for ; Sat, 31 Dec 2011 06:28:42 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id DBA2D21F844E for ; Sat, 31 Dec 2011 06:28:41 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 31 Dec 2011 09:28:25 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <9510D26531EF184D9017DF24659BB87F3311080B41@EMV65-UKRD.domain1.systemhost.net> Date: Sat, 31 Dec 2011 08:28:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC4690C.2060707@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F3311080B41@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1084) Cc: conex@ietf.org Subject: Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.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: Sat, 31 Dec 2011 14:28:42 -0000 Hi Phil, Thanks. I have entered these into the tracker. Just one question below = -- On Dec 19, 2011, at 2:29 AM, = wrote: > S2.3 para 1, "measures" -> "is" (twice) - think this would be better = as you're defining what rest-of-path & upstream congestion are >=20 I don't understand what you mean by "this." Best, Alissa > Last para of S3, p10. There's a bit of a jump from the penultimate = sentence about flat rate pricing to the last sentence about conex. Needs = some linking >=20 > S4, Enabling more efficient capacity provisioning - this para is hard = to follow, it twists around a bit. Also, change title to Enabling more = efficient usage of capacity? I think it may be simpler to split into a = use case which is user-focussed (about scavenger) and another which is = operator-focussed. >=20 > S5 para 2 "strong incentive to tell the network .. data" -> "some = incentive to deploy conex" >=20 > Para 3, Specifies -> proposes (so you don't have to wait for the = conex-tcp draft) >=20 >=20 >=20 > Philip Eardley =20 > Research and Technology Strategy >=20 > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf = Of marcelo bagnulo braun > Sent: 17 November 2011 01:53 > To: 'ConEx IETF list' > Subject: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt >=20 > This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt. > (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt) >=20 > Please review the document and send comments before the 5th december. >=20 > Thanks, marcelo > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From tm444@hermes.cam.ac.uk Sat Dec 31 07:34:04 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 2384521F8482 for ; Sat, 31 Dec 2011 07:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfZSHZd+WxGk for ; Sat, 31 Dec 2011 07:34:03 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0255821F8480 for ; Sat, 31 Dec 2011 07:34:02 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:55814) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:tm444) id 1Rh0wa-0003yA-qC (Exim 4.72) (return-path ); Sat, 31 Dec 2011 15:34:00 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:tm444) id 1Rh0wa-0001Wd-4x (Exim 4.67) (return-path ); Sat, 31 Dec 2011 15:34:00 +0000 Received: from [128.232.235.161] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 31 Dec 2011 15:34:00 +0000 Date: 31 Dec 2011 15:34:00 +0000 From: Toby Moncaster To: Alissa Cooper Message-ID: In-Reply-To: References: <4EC4690C.2060707@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F3311080B41@EMV65-UKRD.domain1.systemhost.net> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: "T. Moncaster" Cc: conex@ietf.org Subject: Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: toby.moncaster@cl.cam.ac.uk List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 15:34:04 -0000 On Dec 31 2011, Alissa Cooper wrote: >Hi Phil, > >Thanks. I have entered these into the tracker. Just one question below -- > > On Dec 19, 2011, at 2:29 AM, > wrote: >> S2.3 para 1, "measures" -> "is" (twice) - think this would be better as >> you're defining what rest-of-path & upstream congestion are >> > >I don't understand what you mean by "this." I think all he is saying is can you change it so it reads more like a definition by using "is" rather than "measures". Then it would read "rest-of-path congestion" (also known as "downstream congestion") is the level of congestion that a traffic flow is expected to experience between the measurement point and its final destination. "Upstream congestion" is the level of congestion experienced up to the measurement point." Toby > >Best, >Alissa > > >> Last para of S3, p10. There's a bit of a jump from the penultimate >> sentence about flat rate pricing to the last sentence about conex. Needs >> some linking >> >> S4, Enabling more efficient capacity provisioning - this para is hard >> to follow, it twists around a bit. Also, change title to Enabling more >> efficient usage of capacity? I think it may be simpler to split into a >> use case which is user-focussed (about scavenger) and another which is >> operator-focussed. >> >> S5 para 2 "strong incentive to tell the network .. data" -> "some >> incentive to deploy conex" >> >> Para 3, Specifies -> proposes (so you don't have to wait for the >> conex-tcp draft) >> >> >> >> Philip Eardley >> Research and Technology Strategy >> >> This email contains BT information, which may be privileged or >> confidential. It's meant only for the individual(s) or entity named >> above. If you're not the intended recipient, note that disclosing, >> copying, distributing or using this information is prohibited. If you've >> received this email in error, please let me know immediately on the >> email address above. Thank you. We monitor our email system, and may >> record your emails. British Telecommunications plc Registered office: 81 >> Newgate Street London EC1A 7AJ Registered in England no: 1800000 >> >> -----Original Message----- From: conex-bounces@ietf.org >> [mailto:conex-bounces@ietf.org] On Behalf Of marcelo bagnulo braun Sent: >> 17 November 2011 01:53 To: 'ConEx IETF list' Subject: [conex] WGLC for >> draft-ietf-conex-concepts-uses-03.txt >> >> This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt. >> (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt) >> >> Please review the document and send comments before the 5th december. >> >> Thanks, 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 >> > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex > From acooper@cdt.org Sat Dec 31 08:32:20 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A021F8464 for ; Sat, 31 Dec 2011 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.859 X-Spam-Level: X-Spam-Status: No, score=-101.859 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubLLl0Drq+wR for ; Sat, 31 Dec 2011 08:32:19 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFBE21F8457 for ; Sat, 31 Dec 2011 08:32:19 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 31 Dec 2011 11:32:03 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: Date: Sat, 31 Dec 2011 10:32:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2792B92B-B826-48B5-B78F-755DA32C3BB2@cdt.org> References: <4EC4690C.2060707@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F3311080B41@EMV65-UKRD.domain1.systemhost.net> To: toby.moncaster@cl.cam.ac.uk X-Mailer: Apple Mail (2.1084) Cc: conex@ietf.org Subject: Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.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: Sat, 31 Dec 2011 16:32:20 -0000 Ah, thanks. I was mis-reading it. On Dec 31, 2011, at 9:34 AM, Toby Moncaster wrote: > On Dec 31 2011, Alissa Cooper wrote: >=20 >> Hi Phil, >>=20 >> Thanks. I have entered these into the tracker. Just one question = below -- >>=20 >> On Dec 19, 2011, at 2:29 AM, = wrote: >>> S2.3 para 1, "measures" -> "is" (twice) - think this would be better = as you're defining what rest-of-path & upstream congestion are >>=20 >> I don't understand what you mean by "this." >=20 > I think all he is saying is can you change it so it reads more like a = definition by using "is" rather than "measures". Then it would read >=20 > "rest-of-path > congestion" (also known as "downstream congestion") is the > level of congestion that a traffic flow is expected to experience > between the measurement point and its final destination. "Upstream > congestion" is the level of congestion experienced up to the > measurement point." >=20 > Toby >=20 >>=20 >> Best, >> Alissa >>=20 >>=20 >>> Last para of S3, p10. There's a bit of a jump from the penultimate = sentence about flat rate pricing to the last sentence about conex. Needs = some linking >>> S4, Enabling more efficient capacity provisioning - this para is = hard to follow, it twists around a bit. Also, change title to Enabling = more efficient usage of capacity? I think it may be simpler to split = into a use case which is user-focussed (about scavenger) and another = which is operator-focussed. >>> S5 para 2 "strong incentive to tell the network .. data" -> "some = incentive to deploy conex" >>> Para 3, Specifies -> proposes (so you don't have to wait for the = conex-tcp draft) >>> Philip Eardley Research and Technology Strategy >>> This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. British Telecommunications plc Registered office: 81 = Newgate Street London EC1A 7AJ Registered in England no: 1800000 >>> -----Original Message----- From: conex-bounces@ietf.org = [mailto:conex-bounces@ietf.org] On Behalf Of marcelo bagnulo braun Sent: = 17 November 2011 01:53 To: 'ConEx IETF list' Subject: [conex] WGLC for = draft-ietf-conex-concepts-uses-03.txt >>> This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt. >>> (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt) >>> Please review the document and send comments before the 5th = december. >>> Thanks, marcelo >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>=20 >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >>=20 >=20