From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Oct 6 16:12:19 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75C21F86F6 for ; Thu, 6 Oct 2011 16:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 oFJu1OTM05uN for ; Thu, 6 Oct 2011 16:12:18 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id B22CE21F86EE for ; Thu, 6 Oct 2011 16:12:18 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 14499633B2; Fri, 7 Oct 2011 01:15:28 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id E3F2259A8A; Fri, 7 Oct 2011 01:15:27 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Fri, 7 Oct 2011 01:15:27 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 23:12:19 -0000 Hi everybody, Richard and I are currently working on the TCP modifications draft. And we get always stocked at the same question how the accounting of the ConEx signal should be done. I believe we assume that the ConEx signal is counted byte-wise that means all bytes of a marked packet are assumed to expose the link congestion. First of all, I have to say hat this is nowhere officially defined. That lead to the following couple of questions: 1. Where do we need to define this? In the IPv6 doc? Because it might be a more general question and it must be clear to everyone that if we account the signal byte-wise this has to be done in the endsystem as well as in every network device using this information. 2. Which bytes of a packet do we take? The IP length incl header, the IP payload incl. TCP header or the actual payload? In TCP if a packet get lost (with SACK) we only know how many payload got lost. We do not know the number of packets/headers that were used to transmit this data. If we would loose one big packet and then retransmit a large number of small packets instead (which are all ConEx marked) that might give quite a different ConEx signal. On the other hand, what causes the congestion is the whole packet incl header(s). What is the right thing to do? Input is very welcome! Thx, Mirja From john@jlc.net Thu Oct 6 16:57: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 DA3CC21F8B5A for ; Thu, 6 Oct 2011 16:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.032 X-Spam-Level: X-Spam-Status: No, score=-106.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 3WNnQgrsSb27 for ; Thu, 6 Oct 2011 16:57:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 50DFB21F8B48 for ; Thu, 6 Oct 2011 16:57:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 52D3A33C22; Thu, 6 Oct 2011 20:00:31 -0400 (EDT) Date: Thu, 6 Oct 2011 20:00:31 -0400 From: John Leslie To: Mirja K?hlewind Message-ID: <20111007000031.GD2234@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 23:57:21 -0000 Mirja K?hlewind wrote: > > Richard and I are currently working on the TCP modifications draft. > And we get always stocked at the same question how the accounting > of the ConEx signal should be done. I believe we assume that the > ConEx signal is counted byte-wise that means all bytes of a marked > packet are assumed to expose the link congestion. Marcello may well believe this needs an "official" answer; I am not convinced it does. From an ISP standpoint, short packets don't necessarily contribute less to congestion. And IMHO, the most important signal of ConEx is that the sender is sending this packet despite a belief it may contribute to congestion. Whether the initial upstream counts marked packets as per-byte, per-packet, or somewhere in between doesn't seem to me to be helpful for us to define at this stage. > First of all, I have to say hat this is nowhere officially defined. > That lead to the following couple of questions: > > 1. Where do we need to define this? In the IPv6 doc? I don't believe we need to define it -- we're likely better to define it _after_ some consensus appears. > Because it might be a more general question and it must be clear > to everyone that if we account the signal byte-wise this has to be > done in the endsystem as well as in every network device using > this information. That's not clear to me... > 2. Which bytes of a packet do we take? The IP length incl header, > the IP payload incl. TCP header or the actual payload? If we were to define this, we'd have to aim for bits-on-the-wire plus some estimate of packet overhead. (IMHO, bits-on-the-wire isn't always clear to the sender.) > In TCP if a packet get lost (with SACK) we only know how many > payload got lost. We do not know the number of packets/headers > that were used to transmit this data. If we would lose one big > packet and then retransmit a large number of small packets instead > (which are all ConEx marked) that might give quite a different > ConEx signal. (That's not an unreasonable case.) > On the other hand, what causes the congestion is the whole packet > incl header(s). What is the right thing to do? I'd punt... For most purposes, I think just counting the marks will suffice; but clearly we shouldn't prohibit experiments counting something else. -- John Leslie From rs@netapp.com Fri Oct 7 03:43:21 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C5A21F877F for ; Fri, 7 Oct 2011 03:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PvtXF4ediyEF for ; Fri, 7 Oct 2011 03:43:21 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC721F8B00 for ; Fri, 7 Oct 2011 03:43:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,501,1312182000"; d="scan'208";a="269317598" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 07 Oct 2011 03:46:32 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p97AkT1Z021392; Fri, 7 Oct 2011 03:46:30 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Oct 2011 12:46:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 11:44:48 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A108AABB2@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20111007000031.GD2234@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Accounting of ConEx signals Thread-Index: AcyEhCbmEuTvOWSgS0q/ennAiuCCHAAVzypA References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> From: "Scheffenegger, Richard" To: "John Leslie" , "Mirja K?hlewind" X-OriginalArrivalTime: 07 Oct 2011 10:46:30.0221 (UTC) FILETIME=[5F3AFFD0:01CC84DE] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 10:43:21 -0000 Hi John, I tend to agree with you - on average, there will be little difference between counting packets, or counting bytes; However, if we don't agree on what is the "correct" approach beforehand and any box is free to account whatever, this may lead to exploits. On another example, if my ISP charges for the congestion volume, it is not irrelevant how this accounting is performed. And as soon as money is involved, this is a high incentive to cheat... IMHO, congestion volume (as defined) is measured in bytes, not packets; and as Conex is a IP-layer mechanism, the natural unit would be full IP packets (IP header + payload), which happens to be readily available by examining the header (although not as quick as simply accounting packets). For the sender transmitting variable sized packets, this may lead to a different number of conex marked packets (but more accurate byte-congestion volume), or vice versa. Richard Scheffenegger >=20 > For most purposes, I think just counting the marks will suffice; > but clearly we shouldn't prohibit experiments counting something else. >=20 > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Fri Oct 7 05:13:00 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583F121F8A69 for ; Fri, 7 Oct 2011 05:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.331 X-Spam-Level: X-Spam-Status: No, score=-106.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 mYyauj9rLZeo for ; Fri, 7 Oct 2011 05:12:59 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A75D421F86DD for ; Fri, 7 Oct 2011 05:12:59 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2544633C22; Fri, 7 Oct 2011 08:16:12 -0400 (EDT) Date: Fri, 7 Oct 2011 08:16:12 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20111007121612.GE2234@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <5FDC413D5FA246468C200652D63E627A108AABB2@LDCMVEXC1-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FDC413D5FA246468C200652D63E627A108AABB2@LDCMVEXC1-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 12:13:00 -0000 Scheffenegger, Richard wrote: > > I tend to agree with you - on average, there will be little difference > between counting packets, or counting bytes; Thank you. > However, if we don't agree on what is the "correct" approach beforehand > and any box is free to account whatever, this may lead to exploits. On > another example, if my ISP charges for the congestion volume, it is not > irrelevant how this accounting is performed. And as soon as money is > involved, this is a high incentive to cheat... Perhaps... It's not clear money _will_ be involved... Recall the history of long-distance phone charges: there were several orders of magnitude difference in charges between different entities. > IMHO, congestion volume (as defined) is measured in bytes, not packets; > and as Conex is a IP-layer mechanism, the natural unit would be full IP > packets (IP header + payload), which happens to be readily available by > examining the header (although not as quick as simply accounting > packets). Readily available to middleboxes, that is. It won't always be readily available to the sender (which I presume would ordinarily be the source of any money changing hands) or receiver (the second most likely). > For the sender transmitting variable sized packets, this may lead to a > different number of conex marked packets (but more accurate > byte-congestion volume), or vice versa. Indeed... But, as an ISP, I doubt I would choose to argue the charges to the sender based on "congestion volume" as defined by some third party. Also, for different tunneling (a very real consideration in IPv6 at the present), the "congestion volume" may be different at different middleboxes. :^( I just don't see the value in this WG "standardizing" how to charge. -- John Leslie From christopher.morrow@gmail.com Fri Oct 7 07:42:40 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F721F889A for ; Fri, 7 Oct 2011 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 frcKve33ZqwQ for ; Fri, 7 Oct 2011 07:42:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7B21F87FA for ; Fri, 7 Oct 2011 07:42:40 -0700 (PDT) Received: by iaby26 with SMTP id y26so5211612iab.31 for ; Fri, 07 Oct 2011 07:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/emFogM1ngdDLG0O2mGPRd13xEJSrNe5Je3XbOu7ciI=; b=BFdyMEX6KeBIc6hueCb8FMQVUPSW/qJo9M/+hN4WPHcD4bUJlV4AAL/g8QH+AGDV2Z G7rdIZqSp0VQ0+/ybGMEijCEGS9zjryH6jT70++SYBqjr1Q3dXz300kB28sF5rBGR8vJ tD8DqSvG+NvhGqCmqX/k/UfcuZcMawDECWqY0= MIME-Version: 1.0 Received: by 10.43.52.136 with SMTP id vm8mr13262096icb.26.1317998753693; Fri, 07 Oct 2011 07:45:53 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.59.206 with HTTP; Fri, 7 Oct 2011 07:45:53 -0700 (PDT) In-Reply-To: <20111007121612.GE2234@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <5FDC413D5FA246468C200652D63E627A108AABB2@LDCMVEXC1-PRD.hq.netapp.com> <20111007121612.GE2234@verdi> Date: Fri, 7 Oct 2011 10:45:53 -0400 X-Google-Sender-Auth: nZIYU2tbZ-Uren9ARUSSrLX4_Ds Message-ID: From: Christopher Morrow To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 14:42:40 -0000 On Fri, Oct 7, 2011 at 8:16 AM, John Leslie wrote: > > =A0 I just don't see the value in this WG "standardizing" how to charge. don't disagree, but I'd point out that 'congestion' (or rather packet drops) happen not just because of full pipes, often packet RATES matter as well. So contributing to high packet rates (even on not full interface by volume) can cause loss. We had a, memerable, customer who ran their interface very hot from a pps perspective while only being ~half full, they were regularly unhappy with loss rates on that interface. -chris small fast packets are often as painful as large slow ones From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Oct 7 07:59:53 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 16BDF21F8C19 for ; Fri, 7 Oct 2011 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 I3ko2vr4RN7t for ; Fri, 7 Oct 2011 07:59:52 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 19C3A21F8C15 for ; Fri, 7 Oct 2011 07:59:49 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6CA9B633B1; Fri, 7 Oct 2011 17:03:00 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5A57B59A8A; Fri, 7 Oct 2011 17:03:00 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: John Leslie Date: Fri, 7 Oct 2011 17:03:00 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> In-Reply-To: <20111007000031.GD2234@verdi> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 14:59:53 -0000 Hi John, I agree with you and Richard that usually it shouldn't make a big difference, but... > > In TCP if a packet get lost (with SACK) we only know how many > > payload got lost. We do not know the number of packets/headers > > that were used to transmit this data. If we would lose one big > > packet and then retransmit a large number of small packets instead > > (which are all ConEx marked) that might give quite a different > > ConEx signal. > > (That's not an unreasonable case.) ... we have to consider those kind on cases if there might be a disadvantage or an advantage or even the possible to cheat the policing system for some users. Mirja From bob.briscoe@bt.com Fri Oct 7 11:07:08 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3128D21F854E for ; Fri, 7 Oct 2011 11:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 qHo4pnPDhtZ9 for ; Fri, 7 Oct 2011 11:07:07 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6721F8560 for ; Fri, 7 Oct 2011 11:07:06 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 19:10:18 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 19:10:18 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1318011018156; Fri, 7 Oct 2011 19:10:18 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p97IACL6013332; Fri, 7 Oct 2011 19:10:12 +0100 Message-Id: <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Oct 2011 19:10:15 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 07 Oct 2011 18:10:18.0826 (UTC) FILETIME=[5F1DAAA0:01CC851C] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 18:07:08 -0000 Mirja, I agree we don't have to standardise how ISPs count congestion-volume. But your & Richard's question comes from a need to write a document defining the experimental ConEx behaviour of /TCP/, not an ISP meter. Audit, not accounting, is the main reason a definitive standard answer is needed. We don't want to trigger the audit function into detecting an attack and dropping packets just because we haven't written interoperable documents. If ConEx signals balance congestion signals (drops or ECN marks) packet-for-packet, but the audit function checks for balance byte-for-byte (or vice versa), then the application could have a problem. Altho Chris is right that you can get packet congestion, the digging behind the byte-pkt draft below found that byte-congestion is predominant on the Internet. And the Internet is like this for good technical reasons. Designers of kit want the forwarding engine to still be in control when it gets congested, so machines are _generally_ designed so the processor can still cope even when the link is flat-lining with small packets. Nonetheless, in order to push the limits on performance, some machines are benchmarked against a workload with a 'typical worst case' mix of small and large packets, rather than actual worst case (all small). So I am afraid the answer is bytes: ConEx signals ought to balance congestion signals (drop or ECN) byte-for-byte. This is unfortunately more difficult to implement starting from existing TCP code. But there's an easier answer. If you can get through an audit function by doing packet-for-packet signalling, when audit is checking byte-for-byte balance, then good luck to you. That's what we did in our implementation, and it seemed OK through an audit function checking bytes. However, we didn't yet go looking for scenarios that would lead to problems. I suggest in the TCP doc we say bytes would be the ideal, but packets is good enough at the experimental stage. In the more general docs, I would ask that we say bytes, so if there are interoperability problems, we have a 'standard' to fall back on that is based on sound technical reasoning. Finally, you are right to ask whether we should have more general guidance to be used when defining ConEx for other transports. We already have this in the two existing w-g docs (see quotes below). 2.1. Definitions ... Congestion-volume: For any granularity of traffic (packet, flow, aggregate, link, etc.), the volume of bytes dropped or marked in a given period of time. Conceptually, data volume multiplied by the instantaneous congestion each packet of the volume experienced. Usually expressed in bytes (or MB, GB, of course). 3.3. Abstract Encoding ... In both cases, the amount of congestion is signaled by the volume of marked data--just as the volume of lost data or ECN marked data signals the amount of congestion experienced. Thus the size of each packet carrying a ConEx Signal is significant. ... 4.4. Audit ... To audit ConEx Signals against actual ECN markings or losses, the auditor could work as follows: monitor flows or aggregates of flows, only holding state on a flow if it first sends a ConEx-Marked packet (Credit or either Re-Echo marking). Count the number of bytes marked with Credit or Re-Echo-ECN. Separately count the number of bytes marked with ECN. Use Credits to assure that {#ECN} <= {#Re-Echo-ECN} + {#Credit}, even though the Re-Echo-ECN markings are delayed by at least one RTT. HTH Bob At 16:03 07/10/2011, Mirja Kuehlewind wrote: >Hi John, > >I agree with you and Richard that usually it shouldn't make a big difference, >but... > > > > In TCP if a packet get lost (with SACK) we only know how many > > > payload got lost. We do not know the number of packets/headers > > > that were used to transmit this data. If we would lose one big > > > packet and then retransmit a large number of small packets instead > > > (which are all ConEx marked) that might give quite a different > > > ConEx signal. > > > > (That's not an unreasonable case.) >... we have to consider those kind on cases if there might be a disadvantage >or an advantage or even the possible to cheat the policing system for some >users. > >Mirja >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From christopher.morrow@gmail.com Fri Oct 7 11:20:54 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D83521F8B5C for ; Fri, 7 Oct 2011 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 T4KTO3cJxzjD for ; Fri, 7 Oct 2011 11:20:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 589B721F8B8F for ; Fri, 7 Oct 2011 11:20:53 -0700 (PDT) Received: by iaby26 with SMTP id y26so5437545iab.31 for ; Fri, 07 Oct 2011 11:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=b3VDB7rFKOzDJiPHAbrOmRkjZiA9oL9kwP/ak6Qf/ro=; b=iTVCROsLsEkYQT4hTSZ8NvaCpAGW/IsEabF32d+vZrvt3JY0bG9mCeGHEI9FdZ5jlv FECbELmudPcWzy+a1T1Up+dAcIKfXFCoC7UXUCKUhFZtzrr06di2ZiISIaVFw+pj+sJr vwlUO2oJc6NZtPiqEjvTK3MQ99AbTDl/BuWf8= MIME-Version: 1.0 Received: by 10.231.27.203 with SMTP id j11mr3800789ibc.10.1318011845701; Fri, 07 Oct 2011 11:24:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.59.206 with HTTP; Fri, 7 Oct 2011 11:24:05 -0700 (PDT) In-Reply-To: <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> Date: Fri, 7 Oct 2011 14:24:05 -0400 X-Google-Sender-Auth: yLkOFAhtquYkzxbuG3_HDvpY-mo Message-ID: From: Christopher Morrow To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 18:20:54 -0000 On Fri, Oct 7, 2011 at 2:10 PM, Bob Briscoe wrote: > Altho Chris is right that you can get packet congestion, the digging behind > the byte-pkt draft below found that byte-congestion is predominant on the > Internet. > > And the Internet is like this for good technical reasons. Designers of kit > want the forwarding engine to still be in control when it gets congested, so > machines are _generally_ designed so the processor can still cope even when > the link is flat-lining with small packets. there is LOTS of kit that behaves very badly with line-rate min-len packets... If part of the reasoning behind conex is 'cost to upgrade', there are likely lots of places using this elderly kit which can't be 'cost effectively' upgraded. Anyway, it seems the discussion is spiraling toward an answer and I was only interested in noting that 'not always is the byte what bites.'. -chris From john@jlc.net Fri Oct 7 15:53:48 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E8921F8C12 for ; Fri, 7 Oct 2011 15:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 X-XuGMpZKaVt for ; Fri, 7 Oct 2011 15:53:48 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5932F21F8BEC for ; Fri, 7 Oct 2011 15:53:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7D52933C22; Fri, 7 Oct 2011 18:57:03 -0400 (EDT) Date: Fri, 7 Oct 2011 18:57:03 -0400 From: John Leslie To: Mirja Kuehlewind Message-ID: <20111007225703.GF2234@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 22:53:48 -0000 Mirja Kuehlewind wrote: > > I agree with you and Richard that usually it shouldn't make a big > difference, but... > >>> In TCP if a packet get lost (with SACK) we only know how many >>> payload got lost. We do not know the number of packets/headers >>> that were used to transmit this data. If we would lose one big >>> packet and then retransmit a large number of small packets instead >>> (which are all ConEx marked) that might give quite a different >>> ConEx signal. >> >> (That's not an unreasonable case.) (But it is yet another case where the sender may be unaware, and the receiver almost certainly will be unaware, of the packet overhead.) > ... we have to consider those kind on cases if there might be a > disadvantage or an advantage or even the possible to cheat the > policing system for some users. I'd prefer we _didn't_ invite random middleboxes to police senders they think are abusing the system. It's not necessary to the information flow, and experience shows it becomes a game of whack-a-mole. :^( -- John Leslie From john@jlc.net Fri Oct 7 16:38:19 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B9421F8B42 for ; Fri, 7 Oct 2011 16:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.341 X-Spam-Level: X-Spam-Status: No, score=-106.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 K6s5EV9IpTkd for ; Fri, 7 Oct 2011 16:38:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8C921F8B0C for ; Fri, 7 Oct 2011 16:38:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BD66B33C23; Fri, 7 Oct 2011 19:41:20 -0400 (EDT) Date: Fri, 7 Oct 2011 19:41:20 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20111007234120.GG2234@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2011 23:38:19 -0000 Bob Briscoe wrote: > > I agree we don't have to standardise how ISPs count > congestion-volume. Thank you. > But your & Richard's question comes from a need to write a document > defining the experimental ConEx behaviour of /TCP/, not an ISP meter. > > Audit, not accounting, is the main reason a definitive standard > answer is needed. We don't want to trigger the audit function into > detecting an attack and dropping packets just because we haven't > written interoperable documents. Agreed: that would be bad... I'd agree that an audit system should be fairly narrowly defined, and the points at which packet drop should be encouraged should be limited. IMHO, packet drop only deserves to be used where severe packet loss is encountered; and clearing Congestion-Expected should be forbidden wherever the _actual_ source of packets is obscure. The simple case -- likely the best for initial experiments -- is to simply disallow policing (understanding that packets _will_ be dropped anyway during DDoS). > If ConEx signals balance congestion signals (drops or ECN marks) > packet-for-packet, but the audit function checks for balance > byte-for-byte (or vice versa), then the application could have a > problem. Indeed! > Altho Chris is right that you can get packet congestion, the digging > behind the byte-pkt draft below found that byte-congestion is > predominant on the Internet. > (in which Bob recommends that "packet size should be taken into account when transports read congestion indications", while "packet size should not be taken into account when network equipment creates congestion signals".) > And the Internet is like this for good technical reasons. Designers > of kit want the forwarding engine to still be in control when it gets > congested, so machines are _generally_ designed so the processor can > still cope even when the link is flat-lining with small packets. Yes... but... Not all designs survive into the products shipped. :^( > Nonetheless, in order to push the limits on performance, some > machines are benchmarked against a workload with a 'typical worst > case' mix of small and large packets, rather than actual worst case > (all small). Alas, yes. (And some particularly nasty things happen in shared-media systems like cable-Internet and wireless.) > So I am afraid the answer is bytes: ConEx signals ought to balance > congestion signals (drop or ECN) byte-for-byte. Strange! I read this data quite the other way: that the answer is count-packets-only. > This is unfortunately more difficult to implement starting from > existing TCP code. But there's an easier answer. If you can get > through an audit function by doing packet-for-packet signalling, when > audit is checking byte-for-byte balance, then good luck to you. > That's what we did in our implementation, and it seemed OK through an > audit function checking bytes. However, we didn't yet go looking for > scenarios that would lead to problems. (As is too often the case, I don't follow Bob's reasoning here.) > I suggest in the TCP doc we say bytes would be the ideal, but packets > is good enough at the experimental stage. I suggest rather saying that packets-only should be counted during the initial experimental stage; but that byte-counting will be studied later on. > In the more general docs, I would ask that we say bytes, so if there > are interoperability problems, we have a 'standard' to fall back on > that is based on sound technical reasoning. "Sound technical reasoning" seems ill-advised here. Packets must pass through a cloud of many different systems under differing managements: essentially none of which will be ruled by "sound technical reasoning". :^( > Finally, you are right to ask whether we should have more general > guidance to be used when defining ConEx for other transports. We > already have this in the two existing w-g docs (see quotes below). > > > 2.1. Definitions > ... > Congestion-volume: For any granularity of traffic (packet, flow, > aggregate, link, etc.), the volume of bytes dropped or marked in a > given period of time. Conceptually, data volume multiplied by the > instantaneous congestion each packet of the volume experienced. > Usually expressed in bytes (or MB, GB, of course). Defining "congestion-volume" doesn't affect how ISPs may regulate congestion-expected marking. > > 3.3. Abstract Encoding > ... > In both cases, the amount of congestion is signaled by the volume of > marked data--just as the volume of lost data or ECN marked data > signals the amount of congestion experienced. Thus the size of each > packet carrying a ConEx Signal is significant. > ... "Amount of congestion" isn't ordinarily considered in TCP congestion management. > 4.4. Audit > ... > To audit ConEx Signals against actual ECN markings or losses, the > auditor could work as follows: monitor flows or aggregates of flows, > only holding state on a flow if it first sends a ConEx-Marked packet > (Credit or either Re-Echo marking). Count the number of bytes marked > with Credit or Re-Echo-ECN. Separately count the number of bytes > marked with ECN. Use Credits to assure that {#ECN} <= {#Re-Echo-ECN} > + {#Credit}, even though the Re-Echo-ECN markings are delayed by at > least one RTT. I don't particularly like this text -- though I understand why it was drafted this way and don't wish to criticize the author. I suppose we'll have to discuss text like this sometime, but that time doesn't feel like now... -- John Leslie From bob.briscoe@bt.com Mon Oct 10 09:15:00 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE121F8B7D for ; Mon, 10 Oct 2011 09:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M795fffiEfpJ for ; Mon, 10 Oct 2011 09:14:59 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id A020721F8B55 for ; Mon, 10 Oct 2011 09:14:58 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 17:14:56 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 17:14:56 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1318263295861; Mon, 10 Oct 2011 17:14:55 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p9AGEqRR003987; Mon, 10 Oct 2011 17:14:53 +0100 Message-Id: <201110101614.p9AGEqRR003987@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Oct 2011 17:14:38 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20111007234120.GG2234@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> <20111007234120.GG2234@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Oct 2011 16:14:56.0592 (UTC) FILETIME=[C061D500:01CC8767] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 16:15:00 -0000 John, At 00:41 08/10/2011, John Leslie wrote: >Bob Briscoe wrote: > > > > I agree we don't have to standardise how ISPs count > > congestion-volume. > > Thank you. > > > But your & Richard's question comes from a need to write a document > > defining the experimental ConEx behaviour of /TCP/, not an ISP meter. > > > > Audit, not accounting, is the main reason a definitive standard > > answer is needed. We don't want to trigger the audit function into > > detecting an attack and dropping packets just because we haven't > > written interoperable documents. > > Agreed: that would be bad... I'd agree that an audit system should >be fairly narrowly defined, and the points at which packet drop should >be encouraged should be limited. IMHO, packet drop only deserves to >be used where severe packet loss is encountered; and clearing >Congestion-Expected should be forbidden wherever the _actual_ source >of packets is obscure. I work on the basis we can't forbid anyone to do anything, where policing is concerned. We can only give them good/useful ways of doing it. > The simple case -- likely the best for initial experiments -- is >to simply disallow policing (understanding that packets _will_ be >dropped anyway during DDoS). Given the real delta ConEx offers is in the policing area, I imagine any experiments will be focused on policing, so it would be futile to disallow them. > > If ConEx signals balance congestion signals (drops or ECN marks) > > packet-for-packet, but the audit function checks for balance > > byte-for-byte (or vice versa), then the application could have a > > problem. > > Indeed! > > > Altho Chris is right that you can get packet congestion, the digging > > behind the byte-pkt draft below found that byte-congestion is > > predominant on the Internet. > > > > (in which Bob recommends that "packet size should be taken into >account when transports read congestion indications", while >"packet size should not be taken into account when network equipment >creates congestion signals".) > > > And the Internet is like this for good technical reasons. Designers > > of kit want the forwarding engine to still be in control when it gets > > congested, so machines are _generally_ designed so the processor can > > still cope even when the link is flat-lining with small packets. > > Yes... but... > > Not all designs survive into the products shipped. :^( You, me, Chris all agree here. That byte congestion is the more prevalent, but packet congestion is by no means irrelevant. > > Nonetheless, in order to push the limits on performance, some > > machines are benchmarked against a workload with a 'typical worst > > case' mix of small and large packets, rather than actual worst case > > (all small). > > Alas, yes. > > (And some particularly nasty things happen in shared-media systems >like cable-Internet and wireless.) Perhaps it would be best to say that the bar to fixing congestion is lower if it's due to packet processing than if it's bytes. For instance, in some of our platforms we trigger alarms to tell us if packet-processor utilisation on an edge router hits 50% a few times. Whereas line utilisation on an edge node might be regularly much higher than that every day and we just consider that normal. > > So I am afraid the answer is bytes: ConEx signals ought to balance > > congestion signals (drop or ECN) byte-for-byte. > > Strange! I read this data quite the other way: that the answer is >count-packets-only. The context of draft-ietf-tsvwg-byte-pkt-congestion is creating congestion signals (packet-based) vs using congestion signals (byte-based). ConEx is all in the "using" space. ConEx doesn't touch the space where signals are created in the first place (AQM etc). I'm not going to repeat the arguments in draft-ietf-tsvwg-byte-pkt-congestion on this list, because you need to sit down with a bag of frozen peas on your head and think hard about it. So it's best to read that draft if you want to do this. If you remember doing probability questions in college, you'll remember it's very easy to make basic mistakes. > > This is unfortunately more difficult to implement starting from > > existing TCP code. But there's an easier answer. If you can get > > through an audit function by doing packet-for-packet signalling, when > > audit is checking byte-for-byte balance, then good luck to you. > > That's what we did in our implementation, and it seemed OK through an > > audit function checking bytes. However, we didn't yet go looking for > > scenarios that would lead to problems. > > (As is too often the case, I don't follow Bob's reasoning here.) Bascially, I'm agreeing with what I think Chris said earlier (or was it Mirja?). Drops (or ECN) will be as likely to hit small as large packets (randomness). Altho ConEx signalling is meant to match drops byte-for-byte, if it's done packet-for-packet, because of the randomness, it will as often be high as low. However, there are probably scenarios that aren't random where matching signals packet-for-packet will lead to a persistent imbalance in byte terms. If these exist (and if the imbalance leads to understatement rather than overstatement), we'll only find out during experiments, then we'll have to assess whether this is serious enough to mandate that TCP ConEx code has to match signals byte-for-byte. > > I suggest in the TCP doc we say bytes would be the ideal, but packets > > is good enough at the experimental stage. > > I suggest rather saying that packets-only should be counted during >the initial experimental stage; but that byte-counting will be studied >later on. Disagree. It would be wrong to say implementers SHOULD do the wrong thing. More correct to say they can probably get away with doing the wrong thing. > > In the more general docs, I would ask that we say bytes, so if there > > are interoperability problems, we have a 'standard' to fall back on > > that is based on sound technical reasoning. > > "Sound technical reasoning" seems ill-advised here. Packets must >pass through a cloud of many different systems under differing >managements: essentially none of which will be ruled by "sound >technical reasoning". :^( As above. Interoperability needs congestion-volume to be in terms of bytes (based on "sound technical reasoning", at least IMHO). So we need to say byte-for-byte is required for interop, then say that packet-by-packet balance will probably be sufficient to achieve sufficient byte-by-byte balance to be interoperable. > > Finally, you are right to ask whether we should have more general > > guidance to be used when defining ConEx for other transports. We > > already have this in the two existing w-g docs (see quotes below). > > > > > > 2.1. Definitions > > ... > > Congestion-volume: For any granularity of traffic (packet, flow, > > aggregate, link, etc.), the volume of bytes dropped or marked in a > > given period of time. Conceptually, data volume multiplied by the > > instantaneous congestion each packet of the volume experienced. > > Usually expressed in bytes (or MB, GB, of course). > > Defining "congestion-volume" doesn't affect how ISPs may regulate >congestion-expected marking. It certainly doesn't affect what they might do. But it does say what they will need to do if they want to measure the economic cost of traffic. I don't think we have to worry about operators counting congested packets, rather than bytes. Operators today measure the number of bytes you send to determine how much you have used their network. They don't often count how many packets you sent. You don't see usage limits in terms of numbers of packets. > > > > 3.3. Abstract Encoding > > ... > > In both cases, the amount of congestion is signaled by the volume of > > marked data--just as the volume of lost data or ECN marked data > > signals the amount of congestion experienced. Thus the size of each > > packet carrying a ConEx Signal is significant. > > ... > > "Amount of congestion" isn't ordinarily considered in TCP congestion >management. Indeed. And one wouldn't expect it to, because transport protocols generally don't do fairness or accounting (even tho for many years numerous researchers thought TCP did fairness, until it was pointed out that fairness depends on how much the user uses the transport, and how many transports the user creates). See > > 4.4. Audit > > ... > > To audit ConEx Signals against actual ECN markings or losses, the > > auditor could work as follows: monitor flows or aggregates of flows, > > only holding state on a flow if it first sends a ConEx-Marked packet > > (Credit or either Re-Echo marking). Count the number of bytes marked > > with Credit or Re-Echo-ECN. Separately count the number of bytes > > marked with ECN. Use Credits to assure that {#ECN} <= {#Re-Echo-ECN} > > + {#Credit}, even though the Re-Echo-ECN markings are delayed by at > > least one RTT. > > I don't particularly like this text -- though I understand why it >was drafted this way and don't wish to criticize the author. > > I suppose we'll have to discuss text like this sometime, but that >time doesn't feel like now... I often notice that you talk about sorting out text later, when we're doing ConEx right now, and we're already behind with milestones. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Oct 10 09:46:37 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAB521F8B30 for ; Mon, 10 Oct 2011 09:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0OeYMZbOOFH0 for ; Mon, 10 Oct 2011 09:46:37 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id A0D9121F8A95 for ; Mon, 10 Oct 2011 09:46:36 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 17:46:33 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 17:46:32 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1318265192434; Mon, 10 Oct 2011 17:46:32 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p9AGkTqw004156; Mon, 10 Oct 2011 17:46:29 +0100 Message-Id: <201110101646.p9AGkTqw004156@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Oct 2011 17:46:06 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Oct 2011 16:46:32.0957 (UTC) FILETIME=[2AB42AD0:01CC876C] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 16:46:37 -0000 Mirja, The thread largely overlooked your second question, which is also a good= one. We haven't got any text anywhere that talks about this. IMO the size should include the network layer header, but not link layer. Reason: ConEx is targeted at the IP layer because=20 it is the interoperability layer across networks.=20 When the bytes of a packet cause congestion=20 (setting aside the discussion about packet=20 processing congestion), the IP header is always=20 there, so it is part of the size that always needs to be counted. So, when we add ConEx to TCP, byte-for-byte=20 balance should strictly take account of IP=20 headers. But as you rightly point out, TCP often=20 doesn't know how many IP headers are involved (or=20 how many TCP headers were involved the last time=20 round the loop). So again, we can only say that=20 the practical approach when coding TCP is to make=20 assumptions about IP and TCP headers (e.g. assume=20 there will always be about the same amount of IP=20 and TCP header size added to the same amount of TCP payload). This should be good enough at this experimental=20 stage. If it raises problems, we will have to deal with them. Bob PS. Strictly, congestion at the link layer=20 includes the size of link layer headers, and=20 congestion in a tunnel includes tunnel headers,=20 etc, etc. But for simplicity, from the=20 transport's viewpoint, I think it's reasonable to=20 use the size of the packet including the one IP=20 header that the transport can assume. This is a=20 bit like the transport layer checksum calculation=20 that includes an IP pseudo-header. But in this=20 case, the transport just adds a pseudo-size for the IP and TCP headers. At 00:15 07/10/2011, Mirja K=FChlewind wrote: >2. Which bytes of a packet do we take? The IP length incl header, the IP >payload incl. TCP header or the actual payload? >In TCP if a packet get lost (with SACK) we only know how many payload got >lost. We do not know the number of packets/headers that were used to= transmit >this data. If we would loose one big packet and then retransmit a large >number of small packets instead (which are all ConEx marked) that might= give >quite a different ConEx signal. On the other hand, what causes the= congestion >is the whole packet incl header(s). What is the right thing to do? ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From john@jlc.net Mon Oct 10 12:37:36 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DFB21F8CC5 for ; Mon, 10 Oct 2011 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-7HR56nRdeW for ; Mon, 10 Oct 2011 12:37:35 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 50A9321F8CC4 for ; Mon, 10 Oct 2011 12:37:35 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8F43533C22; Mon, 10 Oct 2011 15:37:33 -0400 (EDT) Date: Mon, 10 Oct 2011 15:37:33 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20111010193733.GF59629@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> <20111007234120.GG2234@verdi> <201110101614.p9AGEqRR003987@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110101614.p9AGEqRR003987@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 19:37:36 -0000 Bob Briscoe wrote: > At 00:41 08/10/2011, John Leslie wrote: >> Bob Briscoe wrote: >>> >>> Audit, not accounting, is the main reason a definitive standard >>> answer is needed. We don't want to trigger the audit function into >>> detecting an attack and dropping packets just because we haven't >>> written interoperable documents. >> >> Agreed: that would be bad... I'd agree that an audit system should >> be fairly narrowly defined, and the points at which packet drop should >> be encouraged should be limited. IMHO, packet drop only deserves to >> be used where severe packet loss is encountered; and clearing >> Congestion-Expected should be forbidden wherever the _actual_ source >> of packets is obscure. > > I work on the basis we can't forbid anyone to do anything, where > policing is concerned. We can only give them good/useful ways of > doing it. We most certainly _can_ forbid doing certain things _if_ you want to claim compliance with the specification we write. Granted, I'm generally happier when we don't forbid very much... >> The simple case -- likely the best for initial experiments -- is >> to simply disallow policing (understanding that packets _will_ be >> dropped anyway during DDoS). > > Given the real delta ConEx offers is in the policing area, (I don't accept that as "given".) > I imagine any experiments will be focused on policing, so it would be > futile to disallow them. "Forbid" may be the wrong word -- we might rather define them as out-of-scope of the ConEx specification. > Perhaps it would be best to say that the bar to fixing congestion is > lower if it's due to packet processing than if it's bytes. > > For instance, in some of our platforms we trigger alarms to tell us > if packet-processor utilisation on an edge router hits 50% a few > times. Whereas line utilisation on an edge node might be regularly > much higher than that every day and we just consider that normal. I'm not sure the two are related -- per-packet overhead tends to dominate designs in the backbone, while per-bit overhead (in the transmission medium) tends to dominate near the edges. >>> So I am afraid the answer is bytes: ConEx signals ought to balance >>> congestion signals (drop or ECN) byte-for-byte. >> >> Strange! I read this data quite the other way: that the answer is >> count-packets-only. > > The context of draft-ietf-tsvwg-byte-pkt-congestion is creating > congestion signals (packet-based) vs using congestion signals > (byte-based). ConEx is all in the "using" space. ConEx doesn't touch > the space where signals are created in the first place (AQM etc). This, I think, is Bob's fundamental argument. I am not convinced that "congestion signals" are necessarily "byte-based". The particular case we're designing for in Active Queue Management, where IMHO the packets are dropped or marked regardless of their size. Furthermore, I'd claim that AQM kicks in more based on average size of all packets in the queue than the particular size of the packet dropped or marked. > I'm not going to repeat the arguments in > draft-ietf-tsvwg-byte-pkt-congestion on this list, because you need > to sit down with a bag of frozen peas on your head and think hard > about it. (I've never tried that!) > So it's best to read that draft if you want to do this. If you > remember doing probability questions in college, you'll remember > it's very easy to make basic mistakes. I _do_ remember that! >>> ... If you can get through an audit function by doing >>> packet-for-packet signalling, when audit is checking byte-for-byte >>> balance, then good luck to you... >> >> (As is too often the case, I don't follow Bob's reasoning here.) > > Bascially, I'm agreeing with what I think Chris said earlier (or was > it Mirja?). Drops (or ECN) will be as likely to hit small as large > packets (randomness). Altho ConEx signalling is meant to match drops > byte-for-byte, if it's done packet-for-packet, because of the > randomness, it will as often be high as low. (Except for the part about "match drops byte-for-byte", I agree.) > However, there are probably scenarios that aren't random where > matching signals packet-for-packet will lead to a persistent > imbalance in byte terms. If these exist (and if the imbalance leads > to understatement rather than overstatement), we'll only find out > during experiments, then we'll have to assess whether this is serious > enough to mandate that TCP ConEx code has to match signals > byte-for-byte. It's hard for me to imagine a situation where that mandate would be appropriate... >>> I suggest in the TCP doc we say bytes would be the ideal, but packets >>> is good enough at the experimental stage. >> >> I suggest rather saying that packets-only should be counted during >> the initial experimental stage; but that byte-counting will be studied >> later on. > > Disagree. It would be wrong to say implementers SHOULD do the wrong > thing. More correct to say they can probably get away with doing the > wrong thing. Why do we need to do either? (And I'm not sure we'd be justified in calling it "the wrong thing.") >>> In the more general docs, I would ask that we say bytes, so if there >>> are interoperability problems, we have a 'standard' to fall back on >>> that is based on sound technical reasoning. >> >> "Sound technical reasoning" seems ill-advised here. Packets must >> pass through a cloud of many different systems under differing >> managements: essentially none of which will be ruled by "sound >> technical reasoning". :^( > > As above. Interoperability needs congestion-volume to be in terms of > bytes (based on "sound technical reasoning", at least IMHO). This is perhaps the crux of the issue: to Bob, "sound technical reasoning" is paramount; to me, it is merely unlikely. I agree that Bob has done his academic work based on "congestion volume" which counts (some) bytes: I don't agree that "congestion volume" is a necessary construct for ConEx -- least of all for early experiments. It's probably time for someone else to weigh in on this... > I often notice that you talk about sorting out text later, when we're > doing ConEx right now, and we're already behind with milestones. Exactly! The more time we spend on details which implementors are likely to ignore, the harder it is to meet deadlines! -- John Leslie From bob.briscoe@bt.com Tue Oct 11 03:24:30 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A07021F8D52 for ; Tue, 11 Oct 2011 03:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 YFKu1mkzrk0L for ; Tue, 11 Oct 2011 03:24:29 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 9F02D21F8D3F for ; Tue, 11 Oct 2011 03:24:28 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 11:24:25 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 11:24:24 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1318328663390; Tue, 11 Oct 2011 11:24:23 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p9BAOMrX008372; Tue, 11 Oct 2011 11:24:22 +0100 Message-Id: <201110111024.p9BAOMrX008372@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Oct 2011 11:24:18 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20111010193733.GF59629@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> <20111007234120.GG2234@verdi> <201110101614.p9AGEqRR003987@bagheera.jungle.bt.co.uk> <20111010193733.GF59629@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 11 Oct 2011 10:24:24.0401 (UTC) FILETIME=[F2A1EC10:01CC87FF] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2011 10:24:30 -0000 John, At 20:37 10/10/2011, John Leslie wrote: >Bob Briscoe wrote: > > At 00:41 08/10/2011, John Leslie wrote: > >> Bob Briscoe wrote: > >>> > >>> Audit, not accounting, is the main reason a definitive standard > >>> answer is needed. We don't want to trigger the audit function into > >>> detecting an attack and dropping packets just because we haven't > >>> written interoperable documents. > >> > >> Agreed: that would be bad... I'd agree that an audit system should > >> be fairly narrowly defined, and the points at which packet drop should > >> be encouraged should be limited. IMHO, packet drop only deserves to > >> be used where severe packet loss is encountered; and clearing > >> Congestion-Expected should be forbidden wherever the _actual_ source > >> of packets is obscure. > > > > I work on the basis we can't forbid anyone to do anything, where > > policing is concerned. We can only give them good/useful ways of > > doing it. > > We most certainly _can_ forbid doing certain things _if_ you want >to claim compliance with the specification we write. > > Granted, I'm generally happier when we don't forbid very much... Also, we're not standardising policing. We're standardising information that might be used for policing. > >> The simple case -- likely the best for initial experiments -- is > >> to simply disallow policing (understanding that packets _will_ be > >> dropped anyway during DDoS). > > > > Given the real delta ConEx offers is in the policing area, > > (I don't accept that as "given".) > > > I imagine any experiments will be focused on policing, so it would be > > futile to disallow them. > > "Forbid" may be the wrong word -- we might rather define them as >out-of-scope of the ConEx specification. Why would experiments involving policing be out of scope of the ConEx spec? Anyway, we were talking about audit. > > Perhaps it would be best to say that the bar to fixing congestion is > > lower if it's due to packet processing than if it's bytes. > > > > For instance, in some of our platforms we trigger alarms to tell us > > if packet-processor utilisation on an edge router hits 50% a few > > times. Whereas line utilisation on an edge node might be regularly > > much higher than that every day and we just consider that normal. > > I'm not sure the two are related -- per-packet overhead tends to >dominate designs in the backbone, while per-bit overhead (in the >transmission medium) tends to dominate near the edges. If the designers of backbone gear have to limit line rate because packet processing would otherwise not keep up, that doesn't mean the packet processor will get congested at run-time. It more likely means they have designed it so the line limit will protect the packet processor from getting congested for typical and perhaps worst-case packet size distributions. > >>> So I am afraid the answer is bytes: ConEx signals ought to balance > >>> congestion signals (drop or ECN) byte-for-byte. > >> > >> Strange! I read this data quite the other way: that the answer is > >> count-packets-only. > > > > The context of draft-ietf-tsvwg-byte-pkt-congestion is creating > > congestion signals (packet-based) vs using congestion signals > > (byte-based). ConEx is all in the "using" space. ConEx doesn't touch > > the space where signals are created in the first place (AQM etc). > > This, I think, is Bob's fundamental argument. I am not convinced >that "congestion signals" are necessarily "byte-based". The particular >case we're designing for in Active Queue Management, where IMHO the >packets are dropped or marked regardless of their size. The last sentence is indeed correct. > Furthermore, I'd claim that AQM kicks in more based on average >size of all packets in the queue than the particular size of the >packet dropped or marked. There's a distinction between the basis on which a machine should measure the queue of all packets, and the basis on which it decides to drop a particular arriving packet. This is explained in draft-ietf-tsvwg-byte-pkt-congestion The draft gives the benefit of all the thoughts and arguments recorded over the years. Let's not continue a conversation based on musings that don't have the benefit of having read the output of an IETF w-g that is working on this. > > I'm not going to repeat the arguments in > > draft-ietf-tsvwg-byte-pkt-congestion on this list, because you need > > to sit down with a bag of frozen peas on your head and think hard > > about it. > > (I've never tried that!) > > > So it's best to read that draft if you want to do this. If you > > remember doing probability questions in college, you'll remember > > it's very easy to make basic mistakes. > > I _do_ remember that! > > >>> ... If you can get through an audit function by doing > >>> packet-for-packet signalling, when audit is checking byte-for-byte > >>> balance, then good luck to you... > >> > >> (As is too often the case, I don't follow Bob's reasoning here.) > > > > Bascially, I'm agreeing with what I think Chris said earlier (or was > > it Mirja?). Drops (or ECN) will be as likely to hit small as large > > packets (randomness). Altho ConEx signalling is meant to match drops > > byte-for-byte, if it's done packet-for-packet, because of the > > randomness, it will as often be high as low. > > (Except for the part about "match drops byte-for-byte", I agree.) On what grounds is your opinion based? You haven't given any reasoning. Otherwise we're just going round in circles. > > However, there are probably scenarios that aren't random where > > matching signals packet-for-packet will lead to a persistent > > imbalance in byte terms. If these exist (and if the imbalance leads > > to understatement rather than overstatement), we'll only find out > > during experiments, then we'll have to assess whether this is serious > > enough to mandate that TCP ConEx code has to match signals > > byte-for-byte. > > It's hard for me to imagine a situation where that mandate would be >appropriate... > > >>> I suggest in the TCP doc we say bytes would be the ideal, but packets > >>> is good enough at the experimental stage. > >> > >> I suggest rather saying that packets-only should be counted during > >> the initial experimental stage; but that byte-counting will be studied > >> later on. > > > > Disagree. It would be wrong to say implementers SHOULD do the wrong > > thing. More correct to say they can probably get away with doing the > > wrong thing. > > Why do we need to do either? > > (And I'm not sure we'd be justified in calling it "the wrong thing.") Again, at the moment, this is an opinion with no reasoning given. > >>> In the more general docs, I would ask that we say bytes, so if there > >>> are interoperability problems, we have a 'standard' to fall back on > >>> that is based on sound technical reasoning. > >> > >> "Sound technical reasoning" seems ill-advised here. Packets must > >> pass through a cloud of many different systems under differing > >> managements: essentially none of which will be ruled by "sound > >> technical reasoning". :^( > > > > As above. Interoperability needs congestion-volume to be in terms of > > bytes (based on "sound technical reasoning", at least IMHO). > > This is perhaps the crux of the issue: to Bob, "sound technical >reasoning" is paramount; to me, it is merely unlikely. I agree that >Bob has done his academic work based on "congestion volume" which >counts (some) bytes: I don't agree that "congestion volume" is a >necessary construct for ConEx -- least of all for early experiments. >It's probably time for someone else to weigh in on this... > > > I often notice that you talk about sorting out text later, when we're > > doing ConEx right now, and we're already behind with milestones. > > Exactly! > > The more time we spend on details which implementors are likely >to ignore, the harder it is to meet deadlines! Mirja is an implementer. She is asking, exactly because this question comes up when you write code. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Oct 11 04:42:49 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011AD21F8D94 for ; Tue, 11 Oct 2011 04:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6] 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 D9zpZ0LaQBt4 for ; Tue, 11 Oct 2011 04:42:48 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 716E821F8D83 for ; Tue, 11 Oct 2011 04:42:46 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 285EF633B2; Tue, 11 Oct 2011 13:42:44 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 157FB59A8A; Tue, 11 Oct 2011 13:42:44 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe Date: Tue, 11 Oct 2011 13:42:43 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <201110101646.p9AGkTqw004156@bagheera.jungle.bt.co.uk> In-Reply-To: <201110101646.p9AGkTqw004156@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201110111342.43331.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2011 11:42:49 -0000 Hi Bob, thanks for this separate answer on the second question but actually your fi= rst=20 answer help me already. When I was reading your mail, I've just though, tha= t=20 we can at the endsystem just count the TCP payload. Under the assumption th= at=20 the endsystem is mostly sending equally sized packets, there will be=20 automatically as many header with ConEx marks as there have been causing th= e=20 original congestion. If the sender is doing some wired things, like sending= =20 smaller retransmit packets, the sender knows about it and can take exactly= =20 this knowledge into account.=20 I talked to Richard about this and he was bring up the case, when there is = ACK=20 congestion (control packets without payload get marked). Not sure what to d= o=20 with this case. If an ACK get lost, we actually don't really know. We could= =20 assume that the receiver should ack as least every second packet but we nev= er=20 know what the receiver did. I believe usually control packets without paylo= ad=20 are as well ECN-capable. So with ECN we would have a congestion signal. Bu= t=20 is this a common case that pure ACKs get ECN markings? Mirja=20 On Monday 10 October 2011 18:46:06 Bob Briscoe wrote: > Mirja, > > The thread largely overlooked your second question, which is also a good > one. > > We haven't got any text anywhere that talks about this. > > IMO the size should include the network layer header, but not link layer. > > Reason: ConEx is targeted at the IP layer because > it is the interoperability layer across networks. > When the bytes of a packet cause congestion > (setting aside the discussion about packet > processing congestion), the IP header is always > there, so it is part of the size that always needs to be counted. > > So, when we add ConEx to TCP, byte-for-byte > balance should strictly take account of IP > headers. But as you rightly point out, TCP often > doesn't know how many IP headers are involved (or > how many TCP headers were involved the last time > round the loop). So again, we can only say that > the practical approach when coding TCP is to make > assumptions about IP and TCP headers (e.g. assume > there will always be about the same amount of IP > and TCP header size added to the same amount of TCP payload). > > This should be good enough at this experimental > stage. If it raises problems, we will have to deal with them. > > > Bob > > PS. Strictly, congestion at the link layer > includes the size of link layer headers, and > congestion in a tunnel includes tunnel headers, > etc, etc. But for simplicity, from the > transport's viewpoint, I think it's reasonable to > use the size of the packet including the one IP > header that the transport can assume. This is a > bit like the transport layer checksum calculation > that includes an IP pseudo-header. But in this > case, the transport just adds a pseudo-size for the IP and TCP headers. > > At 00:15 07/10/2011, Mirja K=FChlewind wrote: > >2. Which bytes of a packet do we take? The IP length incl header, the IP > >payload incl. TCP header or the actual payload? > >In TCP if a packet get lost (with SACK) we only know how many payload got > >lost. We do not know the number of packets/headers that were used to > > transmit this data. If we would loose one big packet and then retransmit > > a large number of small packets instead (which are all ConEx marked) th= at > > might give quite a different ConEx signal. On the other hand, what caus= es > > the congestion is the whole packet incl header(s). What is the right > > thing to do? > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From bob.briscoe@bt.com Tue Oct 11 05:35:14 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504EE21F8C6E for ; Tue, 11 Oct 2011 05:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6] 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 UCK0jvr5XB77 for ; Tue, 11 Oct 2011 05:35:13 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3D321F8C14 for ; Tue, 11 Oct 2011 05:35:12 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 13:35:10 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 13:35:10 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1318336509554; Tue, 11 Oct 2011 13:35:09 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p9BCZ5eO008809; Tue, 11 Oct 2011 13:35:05 +0100 Message-Id: <201110111235.p9BCZ5eO008809@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Oct 2011 13:35:04 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201110111342.43331.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <201110101646.p9AGkTqw004156@bagheera.jungle.bt.co.uk> <201110111342.43331.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 11 Oct 2011 12:35:10.0438 (UTC) FILETIME=[373C2860:01CC8812] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2011 12:35:14 -0000 Mirja, If pure acks were ECN-capable, it would be just=20 as likely that they would get an ECN mark as any=20 data packet. However, RFC3168 says pure ACKS must=20 be sent as Not-ECT. We should keep to this in=20 ConEx unless something better has been done that=20 I'm not aware of - ConEx isn't chartered to work on loss/marking of pure= acks. There is RFC5690, which is informational (rather than experimental): "Adding Acknowledgement Congestion Control to TCP" The relevant section in the re-ECN spec about=20 pure acks, and byte vs packet ConEx signalling is=20 here, which covers nearly everything in the present thread: This leaves the outstanding question of which=20 ConEx doc should write about this stuff. * abstract-mech ought to cover things like which packet headers to include. * conex-tcp-modifications obviously ought to talk about TCP-specifics * that leaves where to put design principles=20 applicable to all transports. 2 options: a) abstract-mech? b) a section in conex-tcp-modifications 'guidelines for other= transports'? I prefer a) but we don't really want extremely detailed stuff in= abstract-mech. Bob At 12:42 11/10/2011, Mirja Kuehlewind wrote: >Hi Bob, > >thanks for this separate answer on the second=20 >question but actually your first >answer help me already. When I was reading your mail, I've just though,= that >we can at the endsystem just count the TCP payload. Under the assumption= that >the endsystem is mostly sending equally sized packets, there will be >automatically as many header with ConEx marks as there have been causing= the >original congestion. If the sender is doing some wired things, like sending >smaller retransmit packets, the sender knows about it and can take exactly >this knowledge into account. > >I talked to Richard about this and he was bring=20 >up the case, when there is ACK >congestion (control packets without payload get marked). Not sure what to= do >with this case. If an ACK get lost, we actually don't really know. We could >assume that the receiver should ack as least every second packet but we= never >know what the receiver did. I believe usually control packets without= payload >are as well ECN-capable. So with ECN we would have a congestion signal.= But >is this a common case that pure ACKs get ECN markings? > >Mirja > > >On Monday 10 October 2011 18:46:06 Bob Briscoe wrote: > > Mirja, > > > > The thread largely overlooked your second question, which is also a good > > one. > > > > We haven't got any text anywhere that talks about this. > > > > IMO the size should include the network layer header, but not link= layer. > > > > Reason: ConEx is targeted at the IP layer because > > it is the interoperability layer across networks. > > When the bytes of a packet cause congestion > > (setting aside the discussion about packet > > processing congestion), the IP header is always > > there, so it is part of the size that always needs to be counted. > > > > So, when we add ConEx to TCP, byte-for-byte > > balance should strictly take account of IP > > headers. But as you rightly point out, TCP often > > doesn't know how many IP headers are involved (or > > how many TCP headers were involved the last time > > round the loop). So again, we can only say that > > the practical approach when coding TCP is to make > > assumptions about IP and TCP headers (e.g. assume > > there will always be about the same amount of IP > > and TCP header size added to the same amount of TCP payload). > > > > This should be good enough at this experimental > > stage. If it raises problems, we will have to deal with them. > > > > > > Bob > > > > PS. Strictly, congestion at the link layer > > includes the size of link layer headers, and > > congestion in a tunnel includes tunnel headers, > > etc, etc. But for simplicity, from the > > transport's viewpoint, I think it's reasonable to > > use the size of the packet including the one IP > > header that the transport can assume. This is a > > bit like the transport layer checksum calculation > > that includes an IP pseudo-header. But in this > > case, the transport just adds a pseudo-size for the IP and TCP headers. > > > > At 00:15 07/10/2011, Mirja K=FChlewind wrote: > > >2. Which bytes of a packet do we take? The IP length incl header, the= IP > > >payload incl. TCP header or the actual payload? > > >In TCP if a packet get lost (with SACK) we only know how many payload= got > > >lost. We do not know the number of packets/headers that were used to > > > transmit this data. If we would loose one big packet and then= retransmit > > > a large number of small packets instead (which are all ConEx marked)= that > > > might give quite a different ConEx signal. On the other hand, what= causes > > > the congestion is the whole packet incl header(s). What is the right > > > thing to do? > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > >-- >------------------------------------------------------------------- >Dipl.-Ing. Mirja K=FChlewind >Institute of Communication Networks and Computer Engineering (IKR) >University of Stuttgart, Germany >Pfaffenwaldring 47, D-70569 Stuttgart > >tel: +49(0)711/685-67973 >email: mirja.kuehlewind@ikr.uni-stuttgart.de >web: www.ikr.uni-stuttgart.de >------------------------------------------------------------------- ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From rs@netapp.com Tue Oct 11 11:07: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 D6AC021F8BD3 for ; Tue, 11 Oct 2011 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6] 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 yERvAL8V6f6i for ; Tue, 11 Oct 2011 11:07:00 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04C21F8DE3 for ; Tue, 11 Oct 2011 11:07:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,524,1312182000"; d="scan'208";a="257213538" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 11 Oct 2011 11:06:59 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p9BI6woG029536; Tue, 11 Oct 2011 11:06:58 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 19:06:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2011 19:05:25 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A10964494@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201110111235.p9BCZ5eO008809@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Accounting of ConEx signals Thread-Index: AcyIEjyroCu4jGfLTYWHCjXVJsIOaAAKu8Ug References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <201110101646.p9AGkTqw004156@bagheera.jungle.bt.co.uk> <201110111342.43331.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110111235.p9BCZ5eO008809@bagheera.jungle.bt.co.uk> From: "Scheffenegger, Richard" To: "Bob Briscoe" , "Mirja Kuehlewind" X-OriginalArrivalTime: 11 Oct 2011 18:06:58.0393 (UTC) FILETIME=[914D0490:01CC8840] Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 11 Oct 2011 18:07:01 -0000 Bob, Mirja, Currently, there are probably two relevant RFCs in this space - RFC5562 = (experimental) and RFC5590 (informational), which Bob already mentioned. RFC5562 adds one specific case of control packets [SYN,ACK] to the = ECT-capable packets. So there exists at least one case, where a pure control packet in TCP = may carry ECN information. RFC5562 is actually implemented and available = in IBM AIX5.3 and later. =20 I believe it should be clear that Conex Marks should only be carried on = those packets, that the transport layer would mark ECN-capable. Further, Section 6.1.5 in RFC3168 also states, that retransmitted = packets should not be sent with ECT. That probably settles the = discussion, if a Conex L mark should be sent right with the = retransmission of the loss. If I'm not mistaken that Conex "requires" a = ECN capable transport (and therefore a qualifying transport segment). However, there are some obvious potential issue with such an approach; = for example, a CE-marked SYN-ACK may never be followed by a data = segement which could carry the Conex E mark for an extensive period of = time. Same could hold for a retransmission which may be the last data to = be sent to the receiver, again for some (human scale) time periods - as = tcp keepalive / window probe windows by definition won't carry ECT / = Conex, correct? Alternatively, Conex marks can be completely decoupled from the = transport (or rather, sent with every packet of that ECN-capable = transport, regardless if the transport actually sends a ECT packet or = not). That would alleviate some of the potential implication a long = delayed conex signal may cause... (Note: reECN implicitly coupled re-ECN marks with ECT, always; but with = the current IPv6 signaling scheme, this is no longer absolutely = required). Best regards, Richard Scheffenegger > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: Dienstag, 11. Oktober 2011 14:35 > To: Mirja Kuehlewind > Cc: conex@ietf.org; Scheffenegger, Richard > Subject: Re: [conex] Accounting of ConEx signals >=20 > Mirja, >=20 > If pure acks were ECN-capable, it would be just > as likely that they would get an ECN mark as any > data packet. However, RFC3168 says pure ACKS must > be sent as Not-ECT. We should keep to this in > ConEx unless something better has been done that > I'm not aware of - ConEx isn't chartered to work on loss/marking of > pure acks. >=20 > There is RFC5690, which is informational (rather than experimental): > "Adding Acknowledgement Congestion Control to TCP" >=20 > The relevant section in the re-ECN spec about > pure acks, and byte vs packet ConEx signalling is > here, which covers nearly everything in the present thread: > 6.1.5> >=20 >=20 > This leaves the outstanding question of which > ConEx doc should write about this stuff. > * abstract-mech ought to cover things like which packet headers to > include. > * conex-tcp-modifications obviously ought to talk about TCP-specifics > * that leaves where to put design principles > applicable to all transports. 2 options: > a) abstract-mech? > b) a section in conex-tcp-modifications 'guidelines for other > transports'? >=20 > I prefer a) but we don't really want extremely detailed stuff in > abstract-mech. >=20 >=20 > Bob >=20 > At 12:42 11/10/2011, Mirja Kuehlewind wrote: > >Hi Bob, > > > >thanks for this separate answer on the second > >question but actually your first > >answer help me already. When I was reading your mail, I've just > though, that > >we can at the endsystem just count the TCP payload. Under the > assumption that > >the endsystem is mostly sending equally sized packets, there will be > >automatically as many header with ConEx marks as there have been > causing the > >original congestion. If the sender is doing some wired things, like > sending > >smaller retransmit packets, the sender knows about it and can take > exactly > >this knowledge into account. > > > >I talked to Richard about this and he was bring > >up the case, when there is ACK > >congestion (control packets without payload get marked). Not sure = what > to do > >with this case. If an ACK get lost, we actually don't really know. We > could > >assume that the receiver should ack as least every second packet but > we never > >know what the receiver did. I believe usually control packets without > payload > >are as well ECN-capable. So with ECN we would have a congestion > signal. But > >is this a common case that pure ACKs get ECN markings? > > > >Mirja > > > > > >On Monday 10 October 2011 18:46:06 Bob Briscoe wrote: > > > Mirja, > > > > > > The thread largely overlooked your second question, which is also = a > good > > > one. > > > > > > We haven't got any text anywhere that talks about this. > > > > > > IMO the size should include the network layer header, but not link > layer. > > > > > > Reason: ConEx is targeted at the IP layer because > > > it is the interoperability layer across networks. > > > When the bytes of a packet cause congestion > > > (setting aside the discussion about packet > > > processing congestion), the IP header is always > > > there, so it is part of the size that always needs to be counted. > > > > > > So, when we add ConEx to TCP, byte-for-byte > > > balance should strictly take account of IP > > > headers. But as you rightly point out, TCP often > > > doesn't know how many IP headers are involved (or > > > how many TCP headers were involved the last time > > > round the loop). So again, we can only say that > > > the practical approach when coding TCP is to make > > > assumptions about IP and TCP headers (e.g. assume > > > there will always be about the same amount of IP > > > and TCP header size added to the same amount of TCP payload). > > > > > > This should be good enough at this experimental > > > stage. If it raises problems, we will have to deal with them. > > > > > > > > > Bob > > > > > > PS. Strictly, congestion at the link layer > > > includes the size of link layer headers, and > > > congestion in a tunnel includes tunnel headers, > > > etc, etc. But for simplicity, from the > > > transport's viewpoint, I think it's reasonable to > > > use the size of the packet including the one IP > > > header that the transport can assume. This is a > > > bit like the transport layer checksum calculation > > > that includes an IP pseudo-header. But in this > > > case, the transport just adds a pseudo-size for the IP and TCP > headers. > > > > > > At 00:15 07/10/2011, Mirja K=FChlewind wrote: > > > >2. Which bytes of a packet do we take? The IP length incl header, > the IP > > > >payload incl. TCP header or the actual payload? > > > >In TCP if a packet get lost (with SACK) we only know how many > payload got > > > >lost. We do not know the number of packets/headers that were used > to > > > > transmit this data. If we would loose one big packet and then > retransmit > > > > a large number of small packets instead (which are all ConEx > marked) that > > > > might give quite a different ConEx signal. On the other hand, > what causes > > > > the congestion is the whole packet incl header(s). What is the > right > > > > thing to do? > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT Innovate & Design > > > > > > > >-- > >------------------------------------------------------------------- > >Dipl.-Ing. Mirja K=FChlewind > >Institute of Communication Networks and Computer Engineering (IKR) > >University of Stuttgart, Germany > >Pfaffenwaldring 47, D-70569 Stuttgart > > > >tel: +49(0)711/685-67973 > >email: mirja.kuehlewind@ikr.uni-stuttgart.de > >web: www.ikr.uni-stuttgart.de > >------------------------------------------------------------------- >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From john@jlc.net Wed Oct 12 03:30:06 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5816521F8C32 for ; Wed, 12 Oct 2011 03:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.197 X-Spam-Level: X-Spam-Status: No, score=-106.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 XUSpRqXA-SZ7 for ; Wed, 12 Oct 2011 03:30:05 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5521F8C20 for ; Wed, 12 Oct 2011 03:30:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A06C833C22; Wed, 12 Oct 2011 06:30:05 -0400 (EDT) Date: Wed, 12 Oct 2011 06:30:05 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20111012103005.GD7021@verdi> References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <20111007000031.GD2234@verdi> <201110071703.00140.mirja.kuehlewind@ikr.uni-stuttgart.de> <201110071810.p97IACL6013332@bagheera.jungle.bt.co.uk> <20111007234120.GG2234@verdi> <201110101614.p9AGEqRR003987@bagheera.jungle.bt.co.uk> <20111010193733.GF59629@verdi> <201110111024.p9BAOMrX008372@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110111024.p9BAOMrX008372@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2011 10:30:06 -0000 Bob Briscoe wrote: > > There's a distinction between the basis on which a machine should > measure the queue of all packets, and the basis on which it decides > to drop a particular arriving packet. This is explained in > draft-ietf-tsvwg-byte-pkt-congestion I do recommend reading this draft... > The draft gives the benefit of all the thoughts and arguments > recorded over the years. Let's not continue a conversation based on > musings that don't have the benefit of having read the output of an > IETF w-g that is working on this. Though it is generally safe to assume an average IETF participant hasn't read any particular draft ;^) Bob should be careful about assuming _I_ haven't read it! I don't have any time today to compose anything useful, but I am willing to get a round tuit if folks find this entertaining... But I wonder if it's worth doing if Bob intends to belittle folks who haven't read this (expired) draft. I can't carry the discussion alone... -- John Leslie From nanditad@google.com Sun Oct 23 22:19:36 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A021F85DB for ; Sun, 23 Oct 2011 22:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 rtL0QdPsOgSD for ; Sun, 23 Oct 2011 22:19:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8496421F8508 for ; Sun, 23 Oct 2011 22:19:35 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p9O5JUUb002406 for ; Sun, 23 Oct 2011 22:19:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319433570; bh=r8+8kZ4Pl+HlYOLP1FoHYMIGitE=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=bQvjMNoEGc2Nhoa90RVXbN8n/SRM/R/DU+KbNk1lK1edbucCDf2ZRwuJ7ohSyo3o6 PSgpdMTU+UryUwr5voY9g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to: content-type:x-system-of-record; b=IApmf6GuFgrlun13wNo6EE3+ppd/m3gdt/t/jKNmqDp3zvdD+xHte0z8wfn5yUMSI 3VhA10raW8nkQJzLoA/LA== Received: from ywm39 (ywm39.prod.google.com [10.192.13.39]) by wpaz29.hot.corp.google.com with ESMTP id p9O5GkKE010563 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 23 Oct 2011 22:19:30 -0700 Received: by ywm39 with SMTP id 39so4125642ywm.2 for ; Sun, 23 Oct 2011 22:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=Xx9WD+R6D1i/oBe4qxMI3AZq4GmxgVqbyMzGV9MG+rU=; b=X9RJdcVl97KGa+OqJDQJSdiz+6m3+xYBjgyUPVFKhsYASXXYZTmbIvgZu8hBoKlwsm GvOpPv94+eQz8xc/F9tw== Received: by 10.229.192.145 with SMTP id dq17mr4672342qcb.68.1319433565984; Sun, 23 Oct 2011 22:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.192.145 with SMTP id dq17mr4672339qcb.68.1319433565853; Sun, 23 Oct 2011 22:19:25 -0700 (PDT) Received: by 10.229.155.10 with HTTP; Sun, 23 Oct 2011 22:19:25 -0700 (PDT) Date: Sun, 23 Oct 2011 22:19:25 -0700 Message-ID: From: Nandita Dukkipati To: conex@ietf.org Content-Type: multipart/alternative; boundary=0016363b860eff58c804b00490a2 X-System-Of-Record: true Subject: [conex] [IETF-82 Conex] Call for presentations X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2011 05:19:36 -0000 --0016363b860eff58c804b00490a2 Content-Type: text/plain; charset=ISO-8859-1 If you would like to present in the Conex session of IETF-82, please email the title and the expected duration of your presentation to the chairs. Thanks! Nandita --0016363b860eff58c804b00490a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you would like to present in the Conex session of IETF-82, please email = the title and the expected duration of your presentation to the chairs.
Thanks!
Nandita=A0
--0016363b860eff58c804b00490a2-- From internet-drafts@ietf.org Tue Oct 25 03:43: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 5EBD721F8B56; Tue, 25 Oct 2011 03:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 UiVRZgaM0OrX; Tue, 25 Oct 2011 03:43:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7DB21F899F; Tue, 25 Oct 2011 03:43:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 03:43:24 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: 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: Tue, 25 Oct 2011 10:43:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : ConEx Concepts and Use Cases Author(s) : Bob Briscoe Richard Woundy Alissa Cooper Filename : draft-ietf-conex-concepts-uses-03.txt Pages : 17 Date : 2011-10-25 This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx field at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated in the ConEx field can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-03.txt From acooper@cdt.org Tue Oct 25 03:50:21 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7021F8B8C for ; Tue, 25 Oct 2011 03:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, 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 RqrKSR3aMgeU for ; Tue, 25 Oct 2011 03:50:20 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29021F8B88 for ; Tue, 25 Oct 2011 03:50:20 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for conex@ietf.org; Tue, 25 Oct 2011 06:50:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Alissa Cooper In-Reply-To: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 11:50:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> References: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> To: ConEx IETF list X-Mailer: Apple Mail (2.1084) Subject: Re: [conex] I-D Action: 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: Tue, 25 Oct 2011 10:50:21 -0000 A new version of draft-ietf-conex-concepts-uses has been submitted: = http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt. There have = been significant changes since the -02 (probably too many to enumerate = in a list here), all with an eye toward making the document simpler and = easier to understand, but the core ideas from the -02 remain. The editors have a few outstanding issues that we will be raising for = discussion on the mailing list, but for now we are looking forward to = your reviews and feedback. Alissa On Oct 25, 2011, at 11:43 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Congestion Exposure = Working Group of the IETF. >=20 > Title : ConEx Concepts and Use Cases > Author(s) : Bob Briscoe > Richard Woundy > Alissa Cooper > Filename : draft-ietf-conex-concepts-uses-03.txt > Pages : 17 > Date : 2011-10-25 >=20 > This document provides the entry point to the set of documentation > about the Congestion Exposure (ConEx) protocol. It explains the > motivation for including a ConEx field at the IP layer: to expose > information about congestion to network nodes. Although such > information may have a number of uses, this document focuses on how > the information communicated in the ConEx field can serve as the > basis for significantly more efficient and effective traffic > management than what exists on the Internet today. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-03.txt > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From internet-drafts@ietf.org Tue Oct 25 08:17:50 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5616021F8BAE; Tue, 25 Oct 2011 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 9ppDNxGzM+Ta; Tue, 25 Oct 2011 08:17:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6F21F8B19; Tue, 25 Oct 2011 08:17:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025151749.15918.75481.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 08:17:49 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:17:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : IPv6 Destination Option for Conex Author(s) : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-00.txt Pages : 6 Date : 2011-10-24 Conex is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying conex markings in IPv6 datagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-destopt-00.txt From john@jlc.net Tue Oct 25 08:25:23 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7C21F8B5A for ; Tue, 25 Oct 2011 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 BGquvi2WajYh for ; Tue, 25 Oct 2011 08:25:23 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2256021F8BE7 for ; Tue, 25 Oct 2011 08:25:23 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2D38233C20; Tue, 25 Oct 2011 11:25:23 -0400 (EDT) Date: Tue, 25 Oct 2011 11:25:23 -0400 From: John Leslie To: Alissa Cooper Message-ID: <20111025152523.GI57720@verdi> References: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> User-Agent: Mutt/1.4.1i Cc: ConEx IETF list Subject: Re: [conex] I-D Action: 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: Tue, 25 Oct 2011 15:25:23 -0000 Alissa Cooper wrote: > > A new version of draft-ietf-conex-concepts-uses has been submitted... My congratulations! Alissa seems to have had many of the same arguments with Bob that I used to have -- and she prevailed! I will send Alissa some purely editorial suggestions: she should share them with the other editors as appropriate. > The editors have a few outstanding issues that we will be raising > for discussion on the mailing list, but for now we are looking > forward to your reviews and feedback. I have several issues which deserve discussion here. concepts-uses still ventures farther into mechanism than I'd wish: - "the ConEx Field" implies mechanism; I suggest "ConEx marking". - "Congestion" vs. "Congestion Volume" needs work. I think I'll do a separate email on that. - "Network provider (or operator)" doesn't work as a definition: I suggest defining "Network Operator (or Provider), and fixing the various places which use these words ambiguously. - The "User" definiton hides something a bit counter-intuitive: that the sending user is known in some places, the receiving user in others, and neither is knowable in the middle. While the definiton here is probably as good as we can get, I'm afraid our readers will be confused. - "Congestion Policer" is not defined. - In Section 3.1, the general-case description of policer (the second paragraph) is describing mechanism better left to a different I-D. OTOH, the fourth and fifth paragraph are an example appropriate for this document (especially since it is the case found in our Charter). -- John Leslie From john@jlc.net Tue Oct 25 08:42:15 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B7721F8BB9 for ; Tue, 25 Oct 2011 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 xw1HRCzSj9Rb for ; Tue, 25 Oct 2011 08:42:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E07821F8B94 for ; Tue, 25 Oct 2011 08:42:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3CCF133C20; Tue, 25 Oct 2011 11:42:15 -0400 (EDT) Date: Tue, 25 Oct 2011 11:42:15 -0400 From: John Leslie To: ConEx IETF list Message-ID: <20111025154215.GJ57720@verdi> References: <20111025104324.3865.89586.idtracker@ietfa.amsl.com> <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AE5704A-620C-46DA-B9DE-E42F9E7F356C@cdt.org> User-Agent: Mutt/1.4.1i Subject: [conex] "Congestion" vs. "Congestion Volume" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 25 Oct 2011 15:42:15 -0000 Alissa Cooper wrote: > > http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt This I-D defines "Congestion" and "Congestion Volume". While the definitions are mostly right IMHO, there are inevitable problems as the terms are used later in the document. Inevitably we must use "level of congestion" in a few places. Which does it refer to? I'd argue that it's not always one or the other. In some places it's clearly bytes-on-the-wire dropped; in others it's clearly percentage of packets dropped. I'd recommend that we clarify that "level of congestion" may have different meanings in different places along the path. Also, we use "quotas" in a few places. The implementation of quotas, IMHO, is unlikely to be the same everywhere. Some quotas will count packets regardless of size; others may count bytes, but are likely to count bytes differently: I doubt we can expect the count to be bytes-on-the-wire consistently. In IPv6, bytes-on-the-wire can differ considerably from bytes of payload, and I would expect some users to argue that they shouldn't be charged for anything beyond payload. As an ISP, I know "winning" such arguments is Pyrrhic. (This much should suffice for starting the discussion. ;^) -- John Leslie From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 26 01:48:23 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9499021F8A69 for ; Wed, 26 Oct 2011 01:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 5+85WwDvJlRV for ; Wed, 26 Oct 2011 01:48:23 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1623421F8A66 for ; Wed, 26 Oct 2011 01:48:20 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E4D55633B1; Wed, 26 Oct 2011 10:48:16 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CE70559A8A; Wed, 26 Oct 2011 10:48:16 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Wed, 26 Oct 2011 10:48:16 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] Expiration of credits X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 08:48:23 -0000 Hi list, one more question, we need to answer for the TCP modifications draft: In the draft we propose a way how to use the credits bits in Slow Start. We assume that the credits are valid for a couple of RTTs. But I assume that those credits should not be valid for ever, as otherwise I could just send credits whenever I have 'congestion volume tokens' available and not care about any conex markings later on. I believe we want to avoid this case. But I don't think that any kind of expiration of the credits bit is addressed yet (in the abstract mechanism draft)...? Mirja From tm444@hermes.cam.ac.uk Wed Oct 26 02:01:16 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062E21F8AF5 for ; Wed, 26 Oct 2011 02:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 2HSbpHwUpeuW for ; Wed, 26 Oct 2011 02:01:15 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1121F8AF4 for ; Wed, 26 Oct 2011 02:01:15 -0700 (PDT) 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]:58210) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1RIzMI-0003tN-DY (Exim 4.72) (return-path ); Wed, 26 Oct 2011 10:01:14 +0100 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Toby Moncaster In-Reply-To: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> Date: Wed, 26 Oct 2011 10:01:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <03258907-BBCC-489F-9220-2C15BB78ECFA@cl.cam.ac.uk> References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1251.1) Sender: "T. Moncaster" Cc: conex@ietf.org Subject: Re: [conex] Expiration of credits X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 09:10:17 -0000 My view would be that the credits would remain valid for the duration of = the connection, but there would be a cap on how much credit you could = have (at most a few packets-worth). Toby On 26 Oct 2011, at 09:48, Mirja K=FChlewind wrote: > Hi list, >=20 > one more question, we need to answer for the TCP modifications draft: >=20 > In the draft we propose a way how to use the credits bits in Slow = Start. We=20 > assume that the credits are valid for a couple of RTTs. But I assume = that=20 > those credits should not be valid for ever, as otherwise I could just = send=20 > credits whenever I have 'congestion volume tokens' available and not = care=20 > about any conex markings later on. I believe we want to avoid this = case. But=20 > I don't think that any kind of expiration of the credits bit is = addressed yet=20 > (in the abstract mechanism draft)...? >=20 > Mirja >=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From john@jlc.net Wed Oct 26 06:20:40 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DB921F8B38 for ; Wed, 26 Oct 2011 06:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.241 X-Spam-Level: X-Spam-Status: No, score=-106.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 xxHfzVub+ewn for ; Wed, 26 Oct 2011 06:20:39 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 240C721F8B31 for ; Wed, 26 Oct 2011 06:20:39 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1F1E433C22; Wed, 26 Oct 2011 09:20:38 -0400 (EDT) Date: Wed, 26 Oct 2011 09:20:38 -0400 From: John Leslie To: Mirja K?hlewind Message-ID: <20111026132038.GL57720@verdi> References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Expiration of credits X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 13:20:40 -0000 Mirja K?hlewind wrote: > > one more question, we need to answer for the TCP modifications draft: > > In the draft we propose a way how to use the credits bits in Slow Start. > We assume that the credits are valid for a couple of RTTs. The credits, IMHO, are intended to cover for one RTT plus processing; but nobody knows how long one RTT is... > But I assume that those credits should not be valid for ever, as > otherwise I could just send credits whenever I have 'congestion > volume tokens' available and not care about any conex markings > later on. I doubt that would prove useful. It is conceivable that someone somewhere might attempt to match "credits" to congestion over a longer period; but I can't see this would accomplish anything useful to the party counting them. A more likely practice would be to accrue an allowance up to a maximum (which might be as low as a half-dozen packets worth or might range up to thousands), and check for a "user" exhausting that allowance. It is far too early, IMHO, to say what these rules might be. Down the road a bit, your upstream may want to traffic-shape so as to fit within a contractual allowance at each peering point. The maximum you could accrue might be a function of traffic patterns at these peering points. > I believe we want to avoid this case. But I don't think that any > kind of expiration of the credits bit is addressed yet (in the > abstract mechanism draft)...? I don't believe that an "expiration" rule will prove helpful; and I certainly don't believe we should try to define one at this stage of the design. And I'm not sure we _could_ attach a useful definition to "valid" here -- packets considered to be part of an "abusive" flow may get dropped somewhere along the path, but that would be a function of the "flow", not the individual "credits", and I can't imagine a practical way to "expire" the "credits". -- John Leslie From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 26 09:08:29 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF921F8876 for ; Wed, 26 Oct 2011 09:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 BqTNxItp--by for ; Wed, 26 Oct 2011 09:08:28 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F51B21F84D6 for ; Wed, 26 Oct 2011 09:08:28 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 57704633B1; Wed, 26 Oct 2011 18:08:26 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4ABE259A8A; Wed, 26 Oct 2011 18:08:26 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Toby Moncaster Date: Wed, 26 Oct 2011 18:08:25 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> <03258907-BBCC-489F-9220-2C15BB78ECFA@cl.cam.ac.uk> In-Reply-To: <03258907-BBCC-489F-9220-2C15BB78ECFA@cl.cam.ac.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201110261808.25587.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Expiration of credits X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 16:08:29 -0000 Hi Toby, I guess a cap is even more complicated. An expiration would somehow depend = on=20 RTT but the num of credit you want to send (at once) depend on the congesti= on=20 control mechanism in the endsystem. If I increase the cwnd by 100 packet in= =20 one RTT I might want to send 100 credits (expect there are still some unuse= d=20 sitting in the audit device from a previous RTT). Mirja On Wednesday 26 October 2011 11:01:14 Toby Moncaster wrote: > My view would be that the credits would remain valid for the duration of > the connection, but there would be a cap on how much credit you could have > (at most a few packets-worth). > > Toby > > On 26 Oct 2011, at 09:48, Mirja K=FChlewind wrote: > > Hi list, > > > > one more question, we need to answer for the TCP modifications draft: > > > > In the draft we propose a way how to use the credits bits in Slow Start. > > We assume that the credits are valid for a couple of RTTs. But I assume > > that those credits should not be valid for ever, as otherwise I could > > just send credits whenever I have 'congestion volume tokens' available > > and not care about any conex markings later on. I believe we want to > > avoid this case. But I don't think that any kind of expiration of the > > credits bit is addressed yet (in the abstract mechanism draft)...? > > > > Mirja > > > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From john@jlc.net Wed Oct 26 09:33:27 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC99E21F8ABB for ; Wed, 26 Oct 2011 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 5alFM4aeDjHS for ; Wed, 26 Oct 2011 09:33:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 27CB521F8593 for ; Wed, 26 Oct 2011 09:33:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 90B8533C21; Wed, 26 Oct 2011 12:33:26 -0400 (EDT) Date: Wed, 26 Oct 2011 12:33:26 -0400 From: John Leslie To: Mirja Kuehlewind Message-ID: <20111026163326.GM57720@verdi> References: <201110261048.16356.mkuehle@ikr.uni-stuttgart.de> <03258907-BBCC-489F-9220-2C15BB78ECFA@cl.cam.ac.uk> <201110261808.25587.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110261808.25587.mirja.kuehlewind@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Expiration of credits X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2011 16:33:27 -0000 Mirja Kuehlewind wrote: > > I guess a cap is even more complicated. An expiration would somehow > depend on RTT but the num of credit you want to send (at once) > depend on the congestion control mechanism in the endsystem. IMHO you should never depend upon a credit lasting more than one RTT. That said, credits are intended for start-up -- and in many cases currently, you will need more than one RTT to infer that a packet was dropped (because ECN marking wasn't enabled at the bottleneck). There may be cases where you should decide whether to issue additional credits while waiting for a timeout -- and there are certainly cases where you _don't_ want to issue such additional credits. > If I increase the cwnd by 100 packet in one RTT I might want to > send 100 credits I cannot imagine such a case. Credits need never exceed the greatest plausible loss. I cannot imagine increasing cwnd by 100 when I expect 100% packet loss. IMHO, credits are not generally appropriate for any situation where you are increasing cwnd -- but I'm sure _someone_ will find a case where it would help... :^} -- John Leslie From internet-drafts@ietf.org Sun Oct 30 07:18: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 051CE21F8B03; Sun, 30 Oct 2011 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 MDNI6daAFZmC; Sun, 30 Oct 2011 07:18:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A956B21F8AD1; Sun, 30 Oct 2011 07:18:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111030141755.21962.83789.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 07:17:55 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-01.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: Sun, 30 Oct 2011 14:18:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : IPv6 Destination Option for Conex Author(s) : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-01.txt Pages : 7 Date : 2011-10-30 Conex is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying conex markings in IPv6 datagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-destopt-01.txt From mirja.kuehlewind@ikr.uni-stuttgart.de Sun Oct 30 13:26:29 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82121F8B62 for ; Sun, 30 Oct 2011 13:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_BAYES_5x7=0.6] 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 kOlbgumRlKTE for ; Sun, 30 Oct 2011 13:26:28 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id EF6DC21F8B18 for ; Sun, 30 Oct 2011 13:26:27 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E9B87633B1; Sun, 30 Oct 2011 21:26:23 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C686459A8A; Sun, 30 Oct 2011 21:26:23 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: "Scheffenegger, Richard" Date: Sun, 30 Oct 2011 21:26:22 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201110070115.27485.mkuehle@ikr.uni-stuttgart.de> <201110111235.p9BCZ5eO008809@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A10964494@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A10964494@LDCMVEXC1-PRD.hq.netapp.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201110302126.22367.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Accounting of ConEx signals X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:26:29 -0000 Hi Richard, after reading the relevant parts of the RFCs stated below again, I would sa= y=20 the answer is more or less obvious. A sender does not have any feedback information (no ECN nor loss detection)= =20 about control packets not carrying any user data. Of course those packets c= an=20 cause congestion as well but neither the sender nor the audit will be able = to=20 detect this congestion. That means a sender can only give conex feedback=20 about the all other packets and this conex information must be seen with=20 respect to only those packets we have congestion information about. Suddenly an IP packet with ConEx header but X bit no set makes sense. I add= ed=20 this to the most current version of the IP Dest Opt draft. SYN and SYN/ACK might be a different case for ECN. But for ConEx as this is= =20 the first packet sent, for sure we do not have any congestion feedback=20 information yet and taking the SYN or SYN/ACK into account when calculating= =20 the congestion level should usually not really make a big difference as you= =20 need anyway a certain amount of packets before you can get a significant=20 result. Regarding the retransmitted packets, we, kind of, have information about, e= ven=20 though they are not ECN-capable, because the RTO might cause a sender to=20 retransmit a restransmitted packet again. The reason for ECN to make=20 retransmitted as not-ECN-capable is because the receiver might not see a=20 unnecessarily-retransmitted packet and thus might not report an CE mark on = an=20 unnecessarily-retransmitted packet to the sender. In our case the ConEx is= =20 meant to be information for network nodes and not for the receiver, thus it= =20 is not a problem. I would recommend to make restransmitted packet=20 ConEx-capable. =46or the TCP modifications draft, we can simply account the TCP payload, w= hen=20 we assume equal sized packets, as the conex marked packet as well as the=20 original packets causing the congestion will both have a header of the same= =20 size.=20 In case of not equal sized packets we have to account the headers as well b= ut=20 we cannot provide a generic way how to do this. A sender which sends=20 different sized packets probably knows about the pattern/reason to do so an= d=20 thus can reconstruct the exact number of headers based on this information. Any thoughts? Mirja On Tuesday 11 October 2011 20:05:25 Scheffenegger, Richard wrote: > Bob, Mirja, > > Currently, there are probably two relevant RFCs in this space - RFC5562 > (experimental) and RFC5590 (informational), which Bob already mentioned. > > RFC5562 adds one specific case of control packets [SYN,ACK] to the > ECT-capable packets. > > So there exists at least one case, where a pure control packet in TCP may > carry ECN information. RFC5562 is actually implemented and available in I= BM > AIX5.3 and later. > > > I believe it should be clear that Conex Marks should only be carried on > those packets, that the transport layer would mark ECN-capable. > > Further, Section 6.1.5 in RFC3168 also states, that retransmitted packets > should not be sent with ECT. That probably settles the discussion, if a > Conex L mark should be sent right with the retransmission of the loss. If > I'm not mistaken that Conex "requires" a ECN capable transport (and > therefore a qualifying transport segment). > > However, there are some obvious potential issue with such an approach; for > example, a CE-marked SYN-ACK may never be followed by a data segement whi= ch > could carry the Conex E mark for an extensive period of time. Same could > hold for a retransmission which may be the last data to be sent to the > receiver, again for some (human scale) time periods - as tcp keepalive / > window probe windows by definition won't carry ECT / Conex, correct? > > > Alternatively, Conex marks can be completely decoupled from the transport > (or rather, sent with every packet of that ECN-capable transport, > regardless if the transport actually sends a ECT packet or not). That wou= ld > alleviate some of the potential implication a long delayed conex signal m= ay > cause... > > (Note: reECN implicitly coupled re-ECN marks with ECT, always; but with t= he > current IPv6 signaling scheme, this is no longer absolutely required). > > Best regards, > > > Richard Scheffenegger > > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: Dienstag, 11. Oktober 2011 14:35 > > To: Mirja Kuehlewind > > Cc: conex@ietf.org; Scheffenegger, Richard > > Subject: Re: [conex] Accounting of ConEx signals > > > > Mirja, > > > > If pure acks were ECN-capable, it would be just > > as likely that they would get an ECN mark as any > > data packet. However, RFC3168 says pure ACKS must > > be sent as Not-ECT. We should keep to this in > > ConEx unless something better has been done that > > I'm not aware of - ConEx isn't chartered to work on loss/marking of > > pure acks. > > > > There is RFC5690, which is informational (rather than experimental): > > "Adding Acknowledgement Congestion Control to TCP" > > > > The relevant section in the re-ECN spec about > > pure acks, and byte vs packet ConEx signalling is > > here, which covers nearly everything in the present thread: > > > 6.1.5> > > > > > > This leaves the outstanding question of which > > ConEx doc should write about this stuff. > > * abstract-mech ought to cover things like which packet headers to > > include. > > * conex-tcp-modifications obviously ought to talk about TCP-specifics > > * that leaves where to put design principles > > applicable to all transports. 2 options: > > a) abstract-mech? > > b) a section in conex-tcp-modifications 'guidelines for other > > transports'? > > > > I prefer a) but we don't really want extremely detailed stuff in > > abstract-mech. > > > > > > Bob > > > > At 12:42 11/10/2011, Mirja Kuehlewind wrote: > > >Hi Bob, > > > > > >thanks for this separate answer on the second > > >question but actually your first > > >answer help me already. When I was reading your mail, I've just > > > > though, that > > > > >we can at the endsystem just count the TCP payload. Under the > > > > assumption that > > > > >the endsystem is mostly sending equally sized packets, there will be > > >automatically as many header with ConEx marks as there have been > > > > causing the > > > > >original congestion. If the sender is doing some wired things, like > > > > sending > > > > >smaller retransmit packets, the sender knows about it and can take > > > > exactly > > > > >this knowledge into account. > > > > > >I talked to Richard about this and he was bring > > >up the case, when there is ACK > > >congestion (control packets without payload get marked). Not sure what > > > > to do > > > > >with this case. If an ACK get lost, we actually don't really know. We > > > > could > > > > >assume that the receiver should ack as least every second packet but > > > > we never > > > > >know what the receiver did. I believe usually control packets without > > > > payload > > > > >are as well ECN-capable. So with ECN we would have a congestion > > > > signal. But > > > > >is this a common case that pure ACKs get ECN markings? > > > > > >Mirja > > > > > >On Monday 10 October 2011 18:46:06 Bob Briscoe wrote: > > > > Mirja, > > > > > > > > The thread largely overlooked your second question, which is also a > > > > good > > > > > > one. > > > > > > > > We haven't got any text anywhere that talks about this. > > > > > > > > IMO the size should include the network layer header, but not link > > > > layer. > > > > > > Reason: ConEx is targeted at the IP layer because > > > > it is the interoperability layer across networks. > > > > When the bytes of a packet cause congestion > > > > (setting aside the discussion about packet > > > > processing congestion), the IP header is always > > > > there, so it is part of the size that always needs to be counted. > > > > > > > > So, when we add ConEx to TCP, byte-for-byte > > > > balance should strictly take account of IP > > > > headers. But as you rightly point out, TCP often > > > > doesn't know how many IP headers are involved (or > > > > how many TCP headers were involved the last time > > > > round the loop). So again, we can only say that > > > > the practical approach when coding TCP is to make > > > > assumptions about IP and TCP headers (e.g. assume > > > > there will always be about the same amount of IP > > > > and TCP header size added to the same amount of TCP payload). > > > > > > > > This should be good enough at this experimental > > > > stage. If it raises problems, we will have to deal with them. > > > > > > > > > > > > Bob > > > > > > > > PS. Strictly, congestion at the link layer > > > > includes the size of link layer headers, and > > > > congestion in a tunnel includes tunnel headers, > > > > etc, etc. But for simplicity, from the > > > > transport's viewpoint, I think it's reasonable to > > > > use the size of the packet including the one IP > > > > header that the transport can assume. This is a > > > > bit like the transport layer checksum calculation > > > > that includes an IP pseudo-header. But in this > > > > case, the transport just adds a pseudo-size for the IP and TCP > > > > headers. > > > > > > At 00:15 07/10/2011, Mirja K=FChlewind wrote: > > > > >2. Which bytes of a packet do we take? The IP length incl header, > > > > the IP > > > > > > >payload incl. TCP header or the actual payload? > > > > >In TCP if a packet get lost (with SACK) we only know how many > > > > payload got > > > > > > >lost. We do not know the number of packets/headers that were used > > > > to > > > > > > > transmit this data. If we would loose one big packet and then > > > > retransmit > > > > > > > a large number of small packets instead (which are all ConEx > > > > marked) that > > > > > > > might give quite a different ConEx signal. On the other hand, > > > > what causes > > > > > > > the congestion is the whole packet incl header(s). What is the > > > > right > > > > > > > thing to do? > > > > > > > > ________________________________________________________________ > > > > Bob Briscoe, BT Innovate & Design > > > > > >-- > > >------------------------------------------------------------------- > > >Dipl.-Ing. Mirja K=FChlewind > > >Institute of Communication Networks and Computer Engineering (IKR) > > >University of Stuttgart, Germany > > >Pfaffenwaldring 47, D-70569 Stuttgart > > > > > >tel: +49(0)711/685-67973 > > >email: mirja.kuehlewind@ikr.uni-stuttgart.de > > >web: www.ikr.uni-stuttgart.de > > >------------------------------------------------------------------- > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From internet-drafts@ietf.org Mon Oct 31 16:41: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 248E711E83BD; Mon, 31 Oct 2011 16:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 K5aBD3+VDmEZ; Mon, 31 Oct 2011 16:41:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24FB11E83B7; Mon, 31 Oct 2011 16:41:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031234103.4395.37761.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:41:03 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: 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, 31 Oct 2011 23:41:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of = the IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechan= ism Author(s) : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-03.txt Pages : 23 Date : 2011-10-31 This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, where it could, for example, be used to provide input to traffic management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-03.txt