From nobody Mon Oct 6 13:52:23 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2C1A8A03 for ; Mon, 6 Oct 2014 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyKJIDd2KdF2 for ; Mon, 6 Oct 2014 13:52:19 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627E11A89C6 for ; Mon, 6 Oct 2014 13:52:19 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 6 Oct 2014 21:52:17 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 6 Oct 2014 21:52:16 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 6 Oct 2014 21:52:16 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.190]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s96KqFQ3003785; Mon, 6 Oct 2014 21:52:15 +0100 Message-ID: <201410062052.s96KqFQ3003785@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 6 Oct 2014 21:52:13 +0100 To: Mirja =?iso-8859-1?Q?K=C3=BChlewind?= , Suresh Krishnan From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/Anh2jZwRM3nT_Codkb744Ym4LuE Cc: "ralli@tid.es" , ConEx IETF list Subject: [conex] draft-ietf-conex-destopt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:52:21 -0000 Mirja, Suresh, I promised (offlist) that I would post the following suggested text to the list for the Security Considerations of conex-destopt. This would replace the current single sentence that simply says "This document does not bring up any new security issues." which doesn't sound very reassuring. HTH Bob ======================================================================================== [abstract-mech] describes the overall audit framework for assuring that ConEx markings truly reflect actual path congestion. This section focuses purely on the security of the encoding chosen for ConEx markings. The chg bit in the CDO option type field is set to zero, meaning that the CDO option is immutable. If IPsec AH is used, a zero chg bit causes AH to cover the CDO option so that its end-to-end integrity can be verified, as explained in Section 4. It has been specified that the Reserved field in the CDO must be ignored and forwarded unchanged even if it does not contain all zeroes. The Reserved field is also required to sit outside the encrypting security payload (ESP), at least in transport mode (see Section 7). This seems to allow the sender to use the Reserved field as a 28-bit-per-packet covert channel to send information to an on-path node outside the control of IPsec. However, a covert channel is only a concern if it can circumvent IPsec in tunnel mode and, in the tunnel mode case, ESP would close the covert channel as outlined in Section 7. ======================================================================================== ________________________________________________________________ Bob Briscoe, BT From nobody Mon Oct 6 15:06:45 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E891A8AE6 for ; Mon, 6 Oct 2014 15:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSnZFqpd7-cU for ; Mon, 6 Oct 2014 15:06:39 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B65E1A8AE9 for ; Mon, 6 Oct 2014 15:06:37 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Oct 2014 23:06:31 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 6 Oct 2014 23:06:34 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 6 Oct 2014 23:06:34 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.190]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s96M6VGI003992; Mon, 6 Oct 2014 23:06:31 +0100 Message-ID: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 6 Oct 2014 23:06:17 +0100 To: Suresh Krishnan From: Bob Briscoe MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_982573607==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/3JmzI9QeiFE3ZZKCbLTtyhYAtls Cc: ConEx IETF list Subject: [conex] Length of conex-destopt? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:06:44 -0000 --=====================_982573607==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Suresh, Is there any reason why the CDO data field is 4 octets long? I think it only needs to consume 1 octet. While I was reviewing conex-destopt I read RFC2460 more carefully than I have done before. I realised I had previously misread this sentence in Section 4: "Each extension header is an integer multiple of 8 octets long". I thought it meant each option had to end on an 8-octet boundary (which is why I specified the re-ECN IPv6 option data length as 4-octets - wrongly I now realise). However, it merely means that the whole destination options extension header must be an integer multiple of 8 octets. According to Section 4.2, each option within the destopt extension header (e.g. CDO) can be any length. Then, if there are more destopts to fit in a packet, IPv6 fits them in one after the other, and adds padding at the end of all the destopts to pad the whole extension header out to a multiple of 8 octets. The IPv6 implementation can also use padding options before any dest opts that contain multi-octet fields that need to be aligned on natural boundaries. So the CDO can be only 1 octet long (plus 2 octets for type and length) as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt type = CDO| Opt data len=1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Resvd | +-+-+-+-+-+-+-+-+ Then, if there are no other destopts in a particular packet, IPv6 would pad it out as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen=0 | Opt type = CDO| Opt data len=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Resvd | PadN type = 1 | Opt data len=1| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where option type 1 is PadN, which in this case uses Opt data length = 1, which means there is 1 octet of zero-padding. On the other hand, if for example a packet needed to contain CDO as well as some new destopt called 'NewOpt', assuming NewOpt has been defined with an alignment requirement of 4n+2 and an opt data length of 6, the destopt extension header would look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen=1 | Opt type = CDO| Opt data len=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Resvd | Pad1 type = 0 | NewOpt type=XX| Opt data len=6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NewOpt data field | PadN type = 1 | Opt data len=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Otherwise, with the 6-octet CDO as previously defined, the destop extension header would have to be much longer, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen=2 | Opt type = CDO| Opt data len=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN type = 1 | Opt data len=0| NewOpt type=XX| Opt data len=6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NewOpt data field | PadN type = 1 | Opt data len=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unless I'm wrong, I think we should change conex-destopt. Thoughts? Bob ________________________________________________________________ Bob Briscoe, BT --=====================_982573607==.ALT Content-Type: text/html; charset="us-ascii" Suresh,

Is there any reason why the CDO data field is 4 octets long? I think it only needs to consume 1 octet.

While I was reviewing conex-destopt I read RFC2460 more carefully than I have done before. I realised I had previously misread this sentence in Section 4: "Each extension header is an integer multiple of 8 octets long".

I thought it meant each option had to end on an 8-octet boundary (which is why I specified the re-ECN IPv6 option data length as 4-octets - wrongly I now realise). However, it merely means that the whole destination options extension header must be an integer multiple of 8 octets.

According to Section 4.2, each option within the destopt extension header (e.g. CDO) can be any length. Then, if there are more destopts to fit in a packet, IPv6 fits them in one after the other, and adds padding at the end of all the destopts to pad the whole extension header out to a multiple of 8 octets. The IPv6 implementation can also use padding options before any dest opts that contain multi-octet fields that need to be aligned on natural boundaries.

So the CDO can be only 1 octet long (plus 2 octets for type and length) as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | Opt type = CDO| Opt data len=1|
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd |
   +-+-+-+-+-+-+-+-+

Then, if there are no other destopts in a particular packet, IPv6 would pad it out as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=0  | Opt type = CDO| Opt data len=1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd | PadN type = 1 | Opt data len=1|       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where option type 1 is PadN, which in this case uses Opt data length = 1, which means there is 1 octet of zero-padding.

On the other hand, if for example a packet needed to contain CDO as well as some new destopt called 'NewOpt', assuming NewOpt has been defined with an alignment requirement of 4n+2 and an opt data length of 6, the destopt extension header would look like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=1  | Opt type = CDO| Opt data len=1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd | Pad1 type = 0 | NewOpt type=XX| Opt data len=6|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       NewOpt data field       | PadN type = 1 | Opt data len=0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Otherwise, with the 6-octet CDO as previously defined, the destop extension header would have to be much longer, as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=2  | Opt type = CDO| Opt data len=4|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C|                   Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN type = 1 | Opt data len=0| NewOpt type=XX| Opt data len=6|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       NewOpt data field       | PadN type = 1 | Opt data len=4|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unless I'm wrong, I think we should change conex-destopt. Thoughts?


Bob

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_982573607==.ALT-- From nobody Tue Oct 7 20:01:34 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0672A1A9033 for ; Tue, 7 Oct 2014 20:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovr8EkcOFjZj for ; Tue, 7 Oct 2014 20:01:30 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547A51A02FC for ; Tue, 7 Oct 2014 20:01:29 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-be-543452196c81 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BC.91.05330.91254345; Tue, 7 Oct 2014 22:50:34 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 23:01:19 -0400 From: Suresh Krishnan To: "bob.briscoe@bt.com" Thread-Topic: Length of conex-destopt? Thread-Index: AQHP4bHNddcZg8ThkUOnRaQaZjnH+5wlhOAh Date: Wed, 8 Oct 2014 03:01:19 +0000 Message-ID: References: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk> In-Reply-To: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF62889F968eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn65UkEmIweX5rBbT139htDh07Sej xYbVU1gcmD3avkxm8liy5CeTx7EPX9kCmKO4bFJSczLLUov07RK4Ml43fGYqaJzIWLFs1zKm BsbTVV2MnBwSAiYSZ+6dYoOwxSQu3FsPZHNxCAkcZZS4c2sBC4SzjFHiUnM3C0gVG1DHhp2f mUBsEQFdiVuvXjCC2MwCORJPnt4AmyQsoCrx7/R6qBo1iZvf57NA2EYSOxZ/B7NZBFQkJr/8 yA5i8wr4SjxqPQhkcwAtc5KYtgSshFPAWeLqlo1gJYxAx30/tYYJYpW4xK0n85kgjhaQWLLn PDOELSrx8vE/VoiafInJy9cxQowXlDg58wnLBEaRWUjaZyEpm4WkDCKuI7Fg9yc2CFtbYtnC 18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy2MQIjKljEmy6Oxj3vLQ8xCjAwajEw7vghlGIEGti WXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwbv27r95y56+7pe7X ls1z3SacPVHGU9D9htPWEqs/fGm/Mxecm1J/lsvdxrBeeM+R3SVJzC/jor5vvFbxICAz+/wk UYn0k68vPRJqkAq3mXD2u/OmWtEIlX/NS75/edL397PWI7dvQs4+tmUC0ivSfZ+/l2Z+Lr3R wn2bVIpz5csNjaXBG98sVGIpzkg01GIuKk4EAFlGfkKKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/conex/dZ1O9iygu7LGlN7U7DS5wZG6WAM Cc: "conex@ietf.org" Subject: Re: [conex] Length of conex-destopt? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 03:01:33 -0000 --_000_E87B771635882B4BA20096B589152EF62889F968eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bob, The reason I made it 4 bytes is for future extensibility and not only for c= urrent use. Since we are defining a new kind of option that signals info to= the network I thought it would be useful for someone who needs such option= in the future to have a few extra bits around as cheap insurance. What do = you think? Thanks Suresh -----Original Message----- From: Bob Briscoe [bob.briscoe@bt.com] Received: Monday, 06 Oct 2014, 6:06PM To: Suresh Krishnan [suresh.krishnan@ericsson.com] CC: Mirja KUEHLEWIND [mirja.kuehlewind@tik.ee.ethz.ch]; ConEx IETF list [co= nex@ietf.org] Subject: Length of conex-destopt? Suresh, Is there any reason why the CDO data field is 4 octets long? I think it onl= y needs to consume 1 octet. While I was reviewing conex-destopt I read RFC2460 more carefully than I ha= ve done before. I realised I had previously misread this sentence in Sectio= n 4: "Each extension header i= s an integer multiple of 8 octets long". I thought it meant each option had to end on an 8-octet boundary (which is = why I specified the re-ECN IPv6 option data length as 4-octets - wrongly I = now realise). However, it merely means that the whole destination options e= xtension header must be an integer multiple of 8 octets. According to Section 4.2, e= ach option within the destopt extension header (e.g. CDO) can be any length= . Then, if there are more destopts to fit in a packet, IPv6 fits them in on= e after the other, and adds padding at the end of all the destopts to pad t= he whole extension header out to a multiple of 8 octets. The IPv6 implement= ation can also use padding options before any dest opts that contain multi-= octet fields that need to be aligned on natural boundaries. So the CDO can be only 1 octet long (plus 2 octets for type and length) as = follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt type =3D CDO| Opt data len=3D1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Resvd | +-+-+-+-+-+-+-+-+ Then, if there are no other destopts in a particular packet, IPv6 would pad= it out as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen=3D0 | Opt type =3D CDO| Opt data len=3D1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Resvd | PadN type =3D 1 | Opt data len=3D1| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where option type 1 is PadN, which in this case uses Opt data length =3D 1,= which means there is 1 octet of zero-padding. On the other hand, if for example a packet needed to contain CDO as well as= some new destopt called 'NewOpt', assuming NewOpt has been defined with an= alignment requirement of 4n+2 and an opt data length of 6, the destopt ext= ension header would look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen=3D1 | Opt type =3D CDO| Opt data len=3D1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Resvd | Pad1 type =3D 0 | NewOpt type=3DXX| Opt data len=3D6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NewOpt data field | PadN type =3D 1 | Opt data len=3D0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Otherwise, with the 6-octet CDO as previously defined, the destop extension= header would have to be much longer, as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen=3D2 | Opt type =3D CDO| Opt data len=3D4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|L|E|C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN type =3D 1 | Opt data len=3D0| NewOpt type=3DXX| Opt data len=3D6= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NewOpt data field | PadN type =3D 1 | Opt data len=3D4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unless I'm wrong, I think we should change conex-destopt. Thoughts? Bob ________________________________________________________________ Bob Briscoe, BT --_000_E87B771635882B4BA20096B589152EF62889F968eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bob,
The reason I made it 4 bytes is for future extensibility and not only for c= urrent use. Since we are defining a new kind of option that signals info to= the network I thought it would be useful for someone who needs such option= in the future to have a few extra bits around as cheap insurance. What do you think?

Thanks
Suresh

-----Original Message-----
From: Bob Briscoe [bob.briscoe@bt.com]
Received: Monday, 06 Oct 2014, 6:06PM
To: Suresh Krishnan [suresh.krishnan@ericsson.com]
CC: Mirja KUEHLEWIND [mirja.kuehlewind@tik.ee.ethz.ch]; ConEx IETF l= ist [conex@ietf.org]
Subject: Length of conex-destopt?

Suresh,

Is there any reason why the CDO data field is 4 octets long? I think it onl= y needs to consume 1 octet.

While I was reviewing conex-destopt I read RFC2460 more carefully than I ha= ve done before. I realised I had previously misread this sentence in Section 4: &qu= ot;Each extension header is an integer multiple of 8 octets long".

I thought it meant each option had to end on an 8-octet boundary (which is = why I specified the re-ECN IPv6 option data length as 4-octets - wrongly I now realise). Ho= wever, it merely means that the whole destination options extension header = must be an integer multiple of 8 octets.

According to Sec= tion 4.2, each option within the destopt extension header (e.g. CDO) ca= n be any length. Then, if there are more destopts to fit in a packet, IPv6 = fits them in one after the other, and adds padding at the end of all the destopts to pad the whole extension= header out to a multiple of 8 octets. The IPv6 implementation can also use= padding options before any dest opts that contain multi-octet fields that = need to be aligned on natural boundaries.

So the CDO can be only 1 octet long (plus 2 octets for type and length) as = follows:

    0         &= nbsp;         1   &n= bsp;            = ;   2          =          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1
            &nb= sp;            =           +-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+
            &nb= sp;            =           | Opt type =3D CDO| = Opt data len=3D1|
   +-+-+-+-+-+-+-+-+ &nb= sp;            = +-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+
   |X|L|E|C| Resvd |
   +-+-+-+-+-+-+-+-+

Then, if there are no other destopts in a particular packet, IPv6 would pad= it out as follows:

    0         &= nbsp;         1   &n= bsp;            = ;   2          =          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=3D0  | Opt ty= pe =3D CDO| Opt data len=3D1|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd | PadN type =3D 1 | Opt data len=3D1| &nb= sp;     0       |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Where option type 1 is PadN, which in this case uses Opt data length =3D 1,= which means there is 1 octet of zero-padding.

On the other hand, if for example a packet needed to contain CDO as well as= some new destopt called 'NewOpt', assuming NewOpt has been defined with an= alignment requirement of 4n+2 and an opt data length of 6, the destopt= extension header would look like this:

    0         &= nbsp;         1   &n= bsp;            = ;   2          =          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=3D1  | Opt ty= pe =3D CDO| Opt data len=3D1|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd | Pad1 type =3D 0 | NewOpt type=3DXX| Opt data= len=3D6|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |
   +         &nb= sp;            =          +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+=
   |       NewOpt data field &= nbsp;     | PadN type =3D 1 | Opt data len=3D0|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Otherwise, with the 6-octet CDO as previously defined, the destop extension= header would have to be much longer, as follows:

    0         &= nbsp;         1   &n= bsp;            = ;   2          =          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=3D2  | Opt ty= pe =3D CDO| Opt data len=3D4|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |X|L|E|C|         = ;          Reserved  = ;            &n= bsp;            = ; |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   | PadN type =3D 1 | Opt data len=3D0| NewOpt type=3DXX| Opt da= ta len=3D6|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  |
   +         &nb= sp;            =          +-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+=
   |       NewOpt data field &= nbsp;     | PadN type =3D 1 | Opt data len=3D4|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |          &= nbsp;           &nbs= p;        0     = ;            &n= bsp;            = ; |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

Unless I'm wrong, I think we should change conex-destopt. Thoughts?


Bob

________________________________________________________________
Bob Briscoe,          &nb= sp;            =             &nb= sp;            =   BT

--_000_E87B771635882B4BA20096B589152EF62889F968eusaamb107erics_-- From nobody Wed Oct 8 01:04:24 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB11A00BA for ; Wed, 8 Oct 2014 01:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Rt4qCz-6lp3 for ; Wed, 8 Oct 2014 01:04:17 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A321A00B6 for ; Wed, 8 Oct 2014 01:04:16 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 8 Oct 2014 09:04:14 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 8 Oct 2014 09:04:14 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 8 Oct 2014 09:04:08 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.156.157]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s98845KE010957; Wed, 8 Oct 2014 09:04:05 +0100 Message-ID: <201410080804.s98845KE010957@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 8 Oct 2014 09:04:05 +0100 To: Suresh Krishnan From: Bob Briscoe In-Reply-To: References: <201410062206.s96M6VGI003992@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1104828330==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/eCvQ7px9LqCq9oOqOlFTkGmsct4 Cc: "conex@ietf.org" Subject: Re: [conex] Length of conex-destopt? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 08:04:22 -0000 --=====================_1104828330==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Suresh, Yeah, I did think that too, but... Another (better?) way to do extensibility is to say that the sender MUST set the CDO option length = 1 but ConEx-aware nodes MUST accept an option length of 1 or longer. However, whatever the length, ConEx-aware nodes read the first 4 bits as defined. Then, if a new spec is ever written, it can define new fields to whatever length it needs. Bob At 04:01 08/10/2014, Suresh Krishnan wrote: >Hi Bob, >The reason I made it 4 bytes is for future extensibility and not >only for current use. Since we are defining a new kind of option >that signals info to the network I thought it would be useful for >someone who needs such option in the future to have a few extra bits >around as cheap insurance. What do you think? > >Thanks >Suresh > >-----Original Message----- >From: Bob Briscoe [bob.briscoe@bt.com] >Received: Monday, 06 Oct 2014, 6:06PM >To: Suresh Krishnan [suresh.krishnan@ericsson.com] >CC: Mirja KUEHLEWIND [mirja.kuehlewind@tik.ee.ethz.ch]; ConEx IETF >list [conex@ietf.org] >Subject: Length of conex-destopt? > >Suresh, > >Is there any reason why the CDO data field is 4 octets long? I think >it only needs to consume 1 octet. > >While I was reviewing conex-destopt I read RFC2460 more carefully >than I have done before. I realised I had previously misread this >sentence in Section 4: >"Each extension header is an integer multiple of 8 octets long". > >I thought it meant each option had to end on an 8-octet boundary >(which is why I specified the >re-ECN >IPv6 option data length as 4-octets - wrongly I now realise). >However, it merely means that the whole destination options >extension header must be an integer multiple of 8 octets. > >According to Section >4.2, each option within the destopt extension header (e.g. CDO) can >be any length. Then, if there are more destopts to fit in a packet, >IPv6 fits them in one after the other, and adds padding at the end >of all the destopts to pad the whole extension header out to a >multiple of 8 octets. The IPv6 implementation can also use padding >options before any dest opts that contain multi-octet fields that >need to be aligned on natural boundaries. > >So the CDO can be only 1 octet long (plus 2 octets for type and >length) as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Opt type = CDO| Opt data len=1| > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X|L|E|C| Resvd | > +-+-+-+-+-+-+-+-+ > >Then, if there are no other destopts in a particular packet, IPv6 >would pad it out as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | HdrExtLen=0 | Opt type = CDO| Opt data len=1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X|L|E|C| Resvd | PadN type = 1 | Opt data len=1| 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Where option type 1 is PadN, which in this case uses Opt data length >= 1, which means there is 1 octet of zero-padding. > >On the other hand, if for example a packet needed to contain CDO as >well as some new destopt called 'NewOpt', assuming NewOpt has been >defined with an alignment requirement of 4n+2 and an opt data length >of 6, the destopt extension header would look like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | HdrExtLen=1 | Opt type = CDO| Opt data len=1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X|L|E|C| Resvd | Pad1 type = 0 | NewOpt type=XX| Opt data len=6| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NewOpt data field | PadN type = 1 | Opt data len=0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Otherwise, with the 6-octet CDO as previously defined, the destop >extension header would have to be much longer, as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | HdrExtLen=2 | Opt type = CDO| Opt data len=4| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |X|L|E|C| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PadN type = 1 | Opt data len=0| NewOpt type=XX| Opt data len=6| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NewOpt data field | PadN type = 1 | Opt data len=4| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Unless I'm wrong, I think we should change conex-destopt. Thoughts? > > >Bob > >________________________________________________________________ >Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT --=====================_1104828330==.ALT Content-Type: text/html; charset="us-ascii" Suresh,

Yeah, I did think that too, but...

Another (better?) way to do extensibility is to say that the sender MUST set the CDO option length = 1 but ConEx-aware nodes MUST accept an option length of 1 or longer. However, whatever the length, ConEx-aware nodes read the first 4 bits as defined.

Then, if a new spec is ever written, it can define new fields to whatever length it needs.


Bob

At 04:01 08/10/2014, Suresh Krishnan wrote:
Hi Bob,
The reason I made it 4 bytes is for future extensibility and not only for current use. Since we are defining a new kind of option that signals info to the network I thought it would be useful for someone who needs such option in the future to have a few extra bits around as cheap insurance. What do you think?

Thanks
Suresh

-----Original Message-----
From: Bob Briscoe [bob.briscoe@bt.com]
Received: Monday, 06 Oct 2014, 6:06PM
To: Suresh Krishnan [suresh.krishnan@ericsson.com]
CC: Mirja KUEHLEWIND [mirja.kuehlewind@tik.ee.ethz.ch]; ConEx IETF list [conex@ietf.org]
Subject: Length of conex-destopt?

Suresh,

Is there any reason why the CDO data field is 4 octets long? I think it only needs to consume 1 octet.

While I was reviewing conex-destopt I read RFC2460 more carefully than I have done before. I realised I had previously misread this sentence in Section 4: "Each extension header is an integer multiple of 8 octets long".

I thought it meant each option had to end on an 8-octet boundary (which is why I specified the re-ECN IPv6 option data length as 4-octets - wrongly I now realise). However, it merely means that the whole destination options extension header must be an integer multiple of 8 octets.

According to Section 4.2, each option within the destopt extension header (e.g. CDO) can be any length. Then, if there are more destopts to fit in a packet, IPv6 fits them in one after the other, and adds padding at the end of all the destopts to pad the whole extension header out to a multiple of 8 octets. The IPv6 implementation can also use padding options before any dest opts that contain multi-octet fields that need to be aligned on natural boundaries.

So the CDO can be only 1 octet long (plus 2 octets for type and length) as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | Opt type = CDO| Opt data len=1|
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd |
   +-+-+-+-+-+-+-+-+

Then, if there are no other destopts in a particular packet, IPv6 would pad it out as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=0  | Opt type = CDO| Opt data len=1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd | PadN type = 1 | Opt data len=1|       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where option type 1 is PadN, which in this case uses Opt data length = 1, which means there is 1 octet of zero-padding.

On the other hand, if for example a packet needed to contain CDO as well as some new destopt called 'NewOpt', assuming NewOpt has been defined with an alignment requirement of 4n+2 and an opt data length of 6, the destopt extension header would look like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=1  | Opt type = CDO| Opt data len=1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C| Resvd | Pad1 type = 0 | NewOpt type=XX| Opt data len=6|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       NewOpt data field       | PadN type = 1 | Opt data len=0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Otherwise, with the 6-octet CDO as previously defined, the destop extension header would have to be much longer, as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  HdrExtLen=2  | Opt type = CDO| Opt data len=4|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|L|E|C|                   Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN type = 1 | Opt data len=0| NewOpt type=XX| Opt data len=6|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       NewOpt data field       | PadN type = 1 | Opt data len=4|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               0                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unless I'm wrong, I think we should change conex-destopt. Thoughts?


Bob

________________________________________________________________
Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_1104828330==.ALT-- From nobody Thu Oct 23 16:24:47 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48401A6EFB for ; Thu, 23 Oct 2014 16:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV29vk1HZxu7 for ; Thu, 23 Oct 2014 16:24:41 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139471A1BC0 for ; Thu, 23 Oct 2014 16:24:41 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id i57so1226055yha.3 for ; Thu, 23 Oct 2014 16:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kg2u1m2DLBu9JwKn5zdq/CBZ8X6BBmp0w77gquUt4aI=; b=SX6MCOS/yVWmYr5b/qz7cQQLSMJn5Xw5qDtCXEMflaQQkLJE1mwl3ww6EGwOnHw3aW r02smWw0zMUwQjWBgfjaIQ8SfpGdfYg3osNxC3r9NPF5R11KiDBLOcGRZTCnXb+E2UN7 PPiJtYsiF3S2wsS8UIWBwVDOrgH6BI0pgt/tdwc4tnF1IMP5VHpn/m19WHbqFtetmxL0 lSWZeD8GmAidR8u6mMGB9WizOtBb3hEr5/Cdha9NR8+gE1Zoa1hfwpwwDguO3X9rTBZ3 2n3a4Hamqf24Apcd/TWwX3snBzPmClo21glTb4al38HEWnULStUH62B8khvdzFFbjZIG IZ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kg2u1m2DLBu9JwKn5zdq/CBZ8X6BBmp0w77gquUt4aI=; b=ZkksoZDaik/jm67saNoACT7gYsvHguWPYVUBFo+4YZmEg4yqO63WktUBc5sWxvdxU3 76J6MUGFY0LtHRK+ExLIlaOodBTI8AcLB6+zU4pJtC2+F9tYp21Qg+n/VucYlAKUnZwQ 542KmiTEuzp7RsUHgYZU40CwpmeI3+3osP8GbgzkJu3hj/NI30A4jbWqE0yGM46goOAp 6hT9ejMbVz2bbzCD2sUZjaoODgqfljKUNYO/FZHWQ196dDN8f2EJjyLzJKTzlYSR3jI/ 83cjifIODbrACn736a/oAopy//UsQOXEpr7X6+GAR/A1toLU3Org6eRCHGqA+HssScM6 PSrA== X-Gm-Message-State: ALoCoQlusUanl76NK1bm4Sy8S0U8WRPIs60UIrhHO79il+yqpafOPndCIiILRQzZGEbYTkxUgS5L MIME-Version: 1.0 X-Received: by 10.170.189.216 with SMTP id g207mr623548yke.45.1414106680221; Thu, 23 Oct 2014 16:24:40 -0700 (PDT) Received: by 10.182.248.161 with HTTP; Thu, 23 Oct 2014 16:24:39 -0700 (PDT) In-Reply-To: <54253A22.2050904@tik.ee.ethz.ch> References: <54253A22.2050904@tik.ee.ethz.ch> Date: Thu, 23 Oct 2014 16:24:39 -0700 Message-ID: From: Nandita Dukkipati To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a1139817e59912905061f5eb1 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/9ZlpX2weVc9Ebdqdeakm4ejRJeg Cc: ConEx IETF list Subject: Re: [conex] TCP mods: Intro X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 23:24:44 -0000 --001a1139817e59912905061f5eb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mirja, Here's the edited version of your text. Inline are a couple of comments. Please pay particular attention to describing what's going into each of the Sections. I found it confusing. Nandita 1. Introduction Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. ConEx concepts and use cases are explained in [RFC6789]. Abstract ConEx mechanism is explained in [draft-ietf-conex-abstract-mech]. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). ConEx marking is defined as a destination option for IPv6 [draft-ietf-conex-destopt]. Specifically, the use of four bits are defined: X (ConEx-capable), the L (loss experienced), the E (ECN experienced) and C (credit) bit. ConEx signal is based on loss or Explicit Congestion Notification (ECN) marks [RFC3168] as a congestion indication. This congestion information is retrieved by the sender based on existing feedback mechanisms from the receiver to the sender in TCP. No changes are needed at the receiver to implement ConEx signaling. Therefore no additional negotiation is needed to implement and use ConEx at the sender. This document specifies actions needed by a sender to provide meaningful ConEx information to the network. Section 2 explains ... Further this document describes congestion accounting for TCP, both with and without the Selective Acknowledgment (SACK) extension [RFC2018] in Section 3.1. However, ConEx benefits from more accurate information about the number of packets dropped in the network. We therefore recommend using the SACK extension when using TCP with ConEx. The detailed mechanism to respectively set the L bit in response to loss-based congestion feedback signal is given in Section 4.1. While loss-based congestion feedback should be minimized, ECN could actuall= y provide more fine-grained feedback information. ConEx-based traffic measurement or management mechanisms would benefit from this. Unfortunately= , the current ECN feedback mechanism does not reflect multiple congestion markings which occur within the same Round-Trip Time (RTT). A more accurate feedback extension to ECN is defined in a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is also useful for other mechanisms. The congestion accounting for both, with the classic ECN feedback as well as a more accurate ECN feedback are explained in detail in section Section 3.2 while the setting of the E bit in response to ECN-based congestion feedback is again detailed in Section 4.1. ---------------------------------------------------------------------------= --------------------------------- On Fri, Sep 26, 2014 at 3:04 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Nandita, hi all, > > find below the current version of the intro. Sorry for the delay; this > week was a little busy... > > I applied the following changes: > > - Paragraph on CDO move back to intro (from section 4) > > - Added paragraph explaining that no receiver side changes are needed > > - Now introducing loss first > > - Added some sentences and the last paragraph to further explain the > structure of the doc > > > Mirja > > ------------------------------------------------------------- > 1. Introduction > > Congestion Exposure (ConEx) is a mechanism by which senders inform > the network about the congestion encountered by previous packets on > the same flow. ConEx concepts and use cases are further explained in > [RFC6789]. The abstract ConEx mechanism is explained in > [draft-ietf-conex-abstract-mech]. This document describes the > necessary modifications to use ConEx with the Transmission Control > Protocol (TCP). > > ConEx is defined as a destination option for IPv6 > [draft-ietf-conex-destopt]. The use of four bits have been defined, > namely the X (ConEx-capable), the L (loss experienced), the E (ECN > experienced) and C (credit) bit. > > Therefore the ConEx signal is based on loss or Explicit Congestion > Notification (ECN) marks [RFC3168] as a congestion indication. This > congestion information is retrieved by the sender based on existing > feedback mechanisms from the receiver to the sender in TCP. No > changes are needed at the receiver to implement ConEx signaling. > Therefore no additional negotiation is needed to implement and use > ConEx at the sender. This document specifies actions needed by > sender to provide meaningful ConEx information to the network in > section Section 2. > > Further this document describes congestion accounting for both TCP > with and without the Selective Acknowledgment (SACK) extension > [RFC2018] in section Section 3.1. However, ConEx benefits from more > accurate information about the number of packets dropped in the > network. We therefore recommend using the SACK extension when using > TCP with ConEx. The detailed mechanism to respectively set the L bit > in response to loss-based congestion feedback signal is given in > section Section 4.1. > > While loss-based congestion feedback should be minimized, ECN could > actually provide more fine-grained feedback information. ConEx-based > traffic measurement or management mechanisms would benefit from this. > Unfortunately, the current ECN feedback mechanism does not reflect > multiple congestion markings which occur within the same Round-Trip > Time (RTT). A more accurate feedback extension to ECN is defined in > a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is > also useful for other mechanisms. > > The congestion accounting for both, with the classic ECN feedback as > well as a more accurate ECN feedback are explained in detail in > section Section 3.2 while the setting of the E bit in response to > ECN-based congestion feedback is again detailed in section > Section 4.1. > --001a1139817e59912905061f5eb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Mirja,

Here's the edited= version of your text.=C2=A0

Inline are a couple o= f comments. Please pay particular attention to describing what's going = into each of the Sections. I found it confusing.

N= andita

1.=C2=A0 Introduction

Cong= estion Exposure (ConEx) is a mechanism by which senders inform=C2=A0the network abo= ut the congestion encountered by previous packets on=C2=A0the same flow.=C2=A0 ConE= x concepts and use cases are explained in=C2=A0[RFC6789]. Abstract ConEx mechanism = is explained in=C2=A0[draft-ietf-conex-abstract-mech].=C2=A0 This document describes the=C2=A0necessary=C2=A0modificat= ions=C2= =A0to use ConEx with the Transmission Control=C2=A0Protocol (TCP).

ConEx marking is defined as a destination option for IPv6= =C2=A0[draft-ie= tf-conex-destopt]. Specifically, the use of four bits are defined:=C2=A0X (ConEx-ca= pable), the L (loss experienced), the E (ECN=C2=A0experienced) and C (credit) bit.<= /span>

ConEx signal is based on loss or Explicit= Congestion=C2=A0Notification (ECN) marks [RFC3168] as a congestion indication.=C2= =A0 This= =C2=A0congestion information is retrieved by the sender based on existing=C2=A0feed= back mechanisms from the receiver to the sender in=C2=A0TCP.=C2=A0 No=C2=A0changes are = needed at the receiver to implement ConEx signaling.=C2=A0Therefore no additional n= egotiation is needed to implement and use=C2=A0ConEx at the sender.=C2=A0 This docu= ment specifies actions needed by a=C2=A0sender to provide meaningful ConEx informat= ion to the network.

<Let the above be the main Intro. Put Section specific information = below.>

Section 2 explains ...
=C2=A0Further this do= cument describes congestion accounting for=C2=A0TCP, both=C2=A0with and without = the Selective Acknowledgment (SACK) extension=C2=A0[RFC2018] in Section 3.1.=C2=A0 = However, ConEx benefits from more=C2=A0accurate information about the number of pac= kets dropped in the=C2=A0network.=C2=A0 We therefore recommend using the SACK exten= sion when using=C2=A0TCP=C2=A0with ConEx. =C2=A0The detailed mechanism to respectively s= et the L bit=C2=A0in response to loss-based congestion feedback signal is given in<= /span>=C2=A0Sec= tion 4.1.

<what happens between the jump= from Section 3.1 to Section 4.1, or should it just be Section 3 and Sectio= n 4? Is Section 3 about congestion accounting w/o SACK and section 4 about = congestion accounting with SACK. Please clarify and rewrite.>
=
While lo= ss-based congestion feedback should be minimized, ECN could=C2=A0actually provide m= ore fine-grained feedback information.=C2=A0 ConEx-based=C2=A0traffic measurement o= r management mechanisms would benefit from this.=C2=A0Unfortunately, the current EC= N feedback mechanism does not reflect=C2=A0multiple congestion markings which occur= within the same Round-Trip=C2=A0Time (RTT).=C2=A0 A more accurate feedback extensi= on to ECN is defined in=C2=A0a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is=C2=A0also useful for ot= her mechanisms.

The congestion accounting for both, with the class= ic ECN feedback as=C2=A0well as a more accurate ECN feedback are explained in detai= l in=C2= =A0section Section 3.2 while the setting of the E bit in response to=C2=A0<= /span>ECN-based= congestion feedback is again detailed in=C2=A0Section 4.1.
<and now I am totally confused :( about the sections: so Section= 4.1 describes the response to both loss and ECN?>

-----------------------------= ---------------------------------------------------------------------------= ----

On Fri,= Sep 26, 2014 at 3:04 AM, Mirja K=C3=BChlewind <mirja.kuehle= wind@tik.ee.ethz.ch> wrote:
Hi Nandita, h= i all,

find below the current version of the intro. Sorry for the delay; this week= was a little busy...

I applied the following changes:

- Paragraph on CDO move back to intro (from section 4)

- Added paragraph explaining that no receiver side changes are needed

- Now introducing loss first

- Added some sentences and the last paragraph to further explain the struct= ure of the doc


Mirja

-------------------------------------------------------------=
1.=C2=A0 Introduction

=C2=A0 =C2=A0Congestion Exposure (ConEx) is a mechanism by which senders in= form
=C2=A0 =C2=A0the network about the congestion encountered by previous packe= ts on
=C2=A0 =C2=A0the same flow.=C2=A0 ConEx concepts and use cases are further = explained in
=C2=A0 =C2=A0[RFC6789].=C2=A0 The abstract ConEx mechanism is explained in<= br> =C2=A0 =C2=A0[draft-ietf-conex-abstract-mech].=C2=A0 This document d= escribes the
=C2=A0 =C2=A0necessary modifications to use ConEx with the Transmission Con= trol
=C2=A0 =C2=A0Protocol (TCP).

=C2=A0 =C2=A0ConEx is defined as a destination option for IPv6
=C2=A0 =C2=A0[draft-ietf-conex-destopt].=C2=A0 The use of four bits have be= en defined,
=C2=A0 =C2=A0namely the X (ConEx-capable), the L (loss experienced), the E = (ECN
=C2=A0 =C2=A0experienced) and C (credit) bit.

=C2=A0 =C2=A0Therefore the ConEx signal is based on loss or Explicit Conges= tion
=C2=A0 =C2=A0Notification (ECN) marks [RFC3168] as a congestion indication.= =C2=A0 This
=C2=A0 =C2=A0congestion information is retrieved by the sender based on exi= sting
=C2=A0 =C2=A0feedback mechanisms from the receiver to the sender in TCP.=C2= =A0 No
=C2=A0 =C2=A0changes are needed at the receiver to implement ConEx signalin= g.
=C2=A0 =C2=A0Therefore no additional negotiation is needed to implement and= use
=C2=A0 =C2=A0ConEx at the sender.=C2=A0 This document specifies actions nee= ded by
=C2=A0 =C2=A0sender to provide meaningful ConEx information to the network = in
=C2=A0 =C2=A0section Section 2.

=C2=A0 =C2=A0Further this document describes congestion accounting for both= TCP
=C2=A0 =C2=A0with and without the Selective Acknowledgment (SACK) extension=
=C2=A0 =C2=A0[RFC2018] in section Section 3.1.=C2=A0 However, ConEx benefit= s from more
=C2=A0 =C2=A0accurate information about the number of packets dropped in th= e
=C2=A0 =C2=A0network.=C2=A0 We therefore recommend using the SACK extension= when using
=C2=A0 =C2=A0TCP with ConEx.=C2=A0 The detailed mechanism to respectively s= et the L bit
=C2=A0 =C2=A0in response to loss-based congestion feedback signal is given = in
=C2=A0 =C2=A0section Section 4.1.

=C2=A0 =C2=A0While loss-based congestion feedback should be minimized, ECN = could
=C2=A0 =C2=A0actually provide more fine-grained feedback information.=C2=A0= ConEx-based
=C2=A0 =C2=A0traffic measurement or management mechanisms would benefit fro= m this.
=C2=A0 =C2=A0Unfortunately, the current ECN feedback mechanism does not ref= lect
=C2=A0 =C2=A0multiple congestion markings which occur within the same Round= -Trip
=C2=A0 =C2=A0Time (RTT).=C2=A0 A more accurate feedback extension to ECN is= defined in
=C2=A0 =C2=A0a separate document [draft-kuehlewind-tcpm-accurate-ecn= ], as this is
=C2=A0 =C2=A0also useful for other mechanisms.

=C2=A0 =C2=A0The congestion accounting for both, with the classic ECN feedb= ack as
=C2=A0 =C2=A0well as a more accurate ECN feedback are explained in detail i= n
=C2=A0 =C2=A0section Section 3.2 while the setting of the E bit in response= to
=C2=A0 =C2=A0ECN-based congestion feedback is again detailed in section
=C2=A0 =C2=A0Section 4.1.

--001a1139817e59912905061f5eb1-- From nobody Fri Oct 24 06:31:09 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1443D1A0072 for ; Fri, 24 Oct 2014 06:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RbZ--ct9D11 for ; Fri, 24 Oct 2014 06:30:50 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D0B1A008A for ; Fri, 24 Oct 2014 06:30:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1B1F9D9309; Fri, 24 Oct 2014 15:30:49 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y64WdUz3lsoJ; Fri, 24 Oct 2014 15:30:48 +0200 (MEST) Received: from mirjas-air.fritz.box (stgt-5f70357e.pool.mediaWays.net [95.112.53.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 836F8D9307; Fri, 24 Oct 2014 15:30:48 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 24 Oct 2014 15:30:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54253A22.2050904@tik.ee.ethz.ch> To: Nandita Dukkipati X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/conex/wXhZYkZiUxKUYhZZFoe2RNOymzM Cc: ConEx IETF list Subject: Re: [conex] TCP mods: Intro X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:30:57 -0000 Hi Nandita, thanks for your feedback. I=E2=80=99ve took over most of your editorial = changes. However, it would more uncomfortable for me if you could = indicate where you propose which changes instead of just editing the = text. Regarding the structure please see the ToC below: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Sender-side Modifications . . . . . . . . . . . . . . . . . . 3 3. Accounting congestion . . . . . . . . . . . . . . . . . . . . 4 3.1. Loss Detection . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Without SACK Support . . . . . . . . . . . . . . . . 5 3.2. ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Accurate ECN feedback . . . . . . . . . . . . . . . . 7 3.2.2. Classic ECN support . . . . . . . . . . . . . . . . . 8 4. Setting the ConEx Bits . . . . . . . . . . . . . . . . . . . 8 4.1. Setting the E and the L Bit . . . . . . . . . . . . . . . 8 4.2. Credit Bits . . . . . . . . . . . . . . . . . . . . . . . 9 5. Loss of ConEx information . . . . . . . . . . . . . . . . . . 10 6. Timeliness of the ConEx Signals . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Revision history . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Would it be helpful if I add a paragraph saying: =E2=80=9ESection 2 provides an overview of the needed modifications for = TCP senders to implement ConEx. =20 First congestion information have to be extracted from loss or ECN = feedback in TCP=20 as described in Section 3. Section 4 details how to set the CDO marking = based on the accounted congestion information.=E2=80=9C Mirja > Am 24.10.2014 um 01:24 schrieb Nandita Dukkipati = : >=20 > Mirja, >=20 > Here's the edited version of your text.=20 >=20 > Inline are a couple of comments. Please pay particular attention to = describing what's going into each of the Sections. I found it confusing. >=20 > Nandita >=20 > 1. Introduction >=20 > Congestion Exposure (ConEx) is a mechanism by which senders inform the = network about the congestion encountered by previous packets on the same = flow. ConEx concepts and use cases are explained in [RFC6789]. Abstract = ConEx mechanism is explained in [draft-ietf-conex-abstract-mech]. This = document describes the necessary modifications to use ConEx with the = Transmission Control Protocol (TCP). >=20 > ConEx marking is defined as a destination option for IPv6 = [draft-ietf-conex-destopt]. Specifically, the use of four bits are = defined: X (ConEx-capable), the L (loss experienced), the E (ECN = experienced) and C (credit) bit. >=20 > ConEx signal is based on loss or Explicit Congestion Notification = (ECN) marks [RFC3168] as a congestion indication. This congestion = information is retrieved by the sender based on existing feedback = mechanisms from the receiver to the sender in TCP. No changes are = needed at the receiver to implement ConEx signaling. Therefore no = additional negotiation is needed to implement and use ConEx at the = sender. This document specifies actions needed by a sender to provide = meaningful ConEx information to the network. >=20 > >=20 > Section 2 explains ... > Further this document describes congestion accounting for TCP, both = with and without the Selective Acknowledgment (SACK) extension [RFC2018] = in Section 3.1. However, ConEx benefits from more accurate information = about the number of packets dropped in the network. We therefore = recommend using the SACK extension when using TCP with ConEx. The = detailed mechanism to respectively set the L bit in response to = loss-based congestion feedback signal is given in Section 4.1. >=20 > >=20 > While loss-based congestion feedback should be minimized, ECN could = actually provide more fine-grained feedback information. ConEx-based = traffic measurement or management mechanisms would benefit from this. = Unfortunately, the current ECN feedback mechanism does not reflect = multiple congestion markings which occur within the same Round-Trip Time = (RTT). A more accurate feedback extension to ECN is defined in a = separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is also = useful for other mechanisms. >=20 > The congestion accounting for both, with the classic ECN feedback as = well as a more accurate ECN feedback are explained in detail in section = Section 3.2 while the setting of the E bit in response to ECN-based = congestion feedback is again detailed in Section 4.1. >=20 > >=20 > = --------------------------------------------------------------------------= ---------------------------------- >=20 > On Fri, Sep 26, 2014 at 3:04 AM, Mirja K=C3=BChlewind = wrote: > Hi Nandita, hi all, >=20 > find below the current version of the intro. Sorry for the delay; this = week was a little busy... >=20 > I applied the following changes: >=20 > - Paragraph on CDO move back to intro (from section 4) >=20 > - Added paragraph explaining that no receiver side changes are needed >=20 > - Now introducing loss first >=20 > - Added some sentences and the last paragraph to further explain the = structure of the doc >=20 >=20 > Mirja >=20 > ------------------------------------------------------------- > 1. Introduction >=20 > Congestion Exposure (ConEx) is a mechanism by which senders inform > the network about the congestion encountered by previous packets on > the same flow. ConEx concepts and use cases are further explained = in > [RFC6789]. The abstract ConEx mechanism is explained in > [draft-ietf-conex-abstract-mech]. This document describes the > necessary modifications to use ConEx with the Transmission Control > Protocol (TCP). >=20 > ConEx is defined as a destination option for IPv6 > [draft-ietf-conex-destopt]. The use of four bits have been = defined, > namely the X (ConEx-capable), the L (loss experienced), the E (ECN > experienced) and C (credit) bit. >=20 > Therefore the ConEx signal is based on loss or Explicit Congestion > Notification (ECN) marks [RFC3168] as a congestion indication. = This > congestion information is retrieved by the sender based on existing > feedback mechanisms from the receiver to the sender in TCP. No > changes are needed at the receiver to implement ConEx signaling. > Therefore no additional negotiation is needed to implement and use > ConEx at the sender. This document specifies actions needed by > sender to provide meaningful ConEx information to the network in > section Section 2. >=20 > Further this document describes congestion accounting for both TCP > with and without the Selective Acknowledgment (SACK) extension > [RFC2018] in section Section 3.1. However, ConEx benefits from = more > accurate information about the number of packets dropped in the > network. We therefore recommend using the SACK extension when = using > TCP with ConEx. The detailed mechanism to respectively set the L = bit > in response to loss-based congestion feedback signal is given in > section Section 4.1. >=20 > While loss-based congestion feedback should be minimized, ECN could > actually provide more fine-grained feedback information. = ConEx-based > traffic measurement or management mechanisms would benefit from = this. > Unfortunately, the current ECN feedback mechanism does not reflect > multiple congestion markings which occur within the same Round-Trip > Time (RTT). A more accurate feedback extension to ECN is defined = in > a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this = is > also useful for other mechanisms. >=20 > The congestion accounting for both, with the classic ECN feedback = as > well as a more accurate ECN feedback are explained in detail in > section Section 3.2 while the setting of the E bit in response to > ECN-based congestion feedback is again detailed in section > Section 4.1. >=20 From nobody Fri Oct 24 13:35:31 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED55F1A1A33; Fri, 24 Oct 2014 13:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56FopSKBZHDc; Fri, 24 Oct 2014 13:35:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3641A1C00; Fri, 24 Oct 2014 13:35:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024203525.9663.27604.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 13:35:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/ZTemM5XWS07V2GDJEz8tKYeqtHc Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-13.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 20:35:29 -0000 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. Title : Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements Authors : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-13.txt Pages : 29 Date : 2014-10-24 Abstract: This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-abstract-mech-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 13:35:54 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C4A1A70E2 for ; Fri, 24 Oct 2014 13:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2-gUGb0LNux for ; Fri, 24 Oct 2014 13:35:35 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582791A6F64 for ; Fri, 24 Oct 2014 13:35:35 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id va2so931898obc.14 for ; Fri, 24 Oct 2014 13:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t5Zt8G10aTs3GQ2hrot29vtQ0we4Vy7gbH2ZzSVPcW4=; b=GAYy/IWAsq+ENiCNgM6ms4eYzPiomOiGyTZ6Opo/xnYitVBY+40dTGHBAs6i+nSF2t CTL5OSbCtV02JdZVZYv5byWubumXAR+rGd8v9yzvm3pqPH1rSm9qSXy61S4OBdrwyNcE 23pLtvmeXPNgLPoazSd5jCLDYukw5RTOwwGDdozOMW1nMXXbNzx+aY/wpQaEqF+U8eZa 0OBmBIeEZysD/hT642joDcOl3XTLmhn7ILyqHmqXLeyQa+txQJ678l3glpah3HnNxDKg +SpNkkn+F4rajDaeQXT2jeEBUvtpQ9zASkQadYtDpy2EzOfIsDXko2aI1QK0QF6Ama9I P6xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t5Zt8G10aTs3GQ2hrot29vtQ0we4Vy7gbH2ZzSVPcW4=; b=HMlY1G+9w959JMWENs11ToA1AgEcqRkKE+tgIwSuA2DAokuMKJbdnfwUwHTrVCJiqA 9xdBWBAGrY7ut9KYYKqqAQixHmwe6UbBXgTR5kZBICwJBSrfLuKlOZerzQvB9hE4SdNB 8HkNPlfxdnawXD7qprrogYFlsTGpzLhYW3rmqgfSVpnPFuIfYAsMzjWSGNX/GFAJZOtB uOBOrkRBH5pLt3U5i508pW0Zeo9Wx2ZFVdb69t6NKjeqwlq7ovytY+122yyZGaRDAlV4 +8+ZB4B/539UwNBbqsyfB5ZFcj1+oXYTIRCwTOi6Z+bdm3uYL/1i/kZu2I41Y29XezX3 LM7g== X-Gm-Message-State: ALoCoQlknBgV2gfc7L+V94esS4h8qiBQ/C5Z5NnoyEuSpoQtcEUlURdcnNLGZ0LS9Y8jqdeZsU8g MIME-Version: 1.0 X-Received: by 10.202.193.138 with SMTP id r132mr3682253oif.52.1414182934597; Fri, 24 Oct 2014 13:35:34 -0700 (PDT) Received: by 10.182.139.69 with HTTP; Fri, 24 Oct 2014 13:35:34 -0700 (PDT) In-Reply-To: <53EA4EFA.9040601@nostrum.com> References: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> <53EA4EFA.9040601@nostrum.com> Date: Fri, 24 Oct 2014 16:35:34 -0400 Message-ID: From: Matt Mathis To: Robert Sparks Content-Type: multipart/alternative; boundary=001a113dc36876fe050506311f82 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/Y81uBknD9vPZ0A-ftx-cKvsVpaA Cc: "ietf@ietf.org" , General Area Review Team , ConEx IETF list , draft-ietf-conex-abstract-mech.all@tools.ietf.org Subject: Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 20:35:38 -0000 --001a113dc36876fe050506311f82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I made one tweak relative to this change as previously agreed: the very last paragraph of the original section was not marked to be deleted but had been pulled up earlier in the section. I deleted the duplicate text. I also changed one word in the abstract, per another LC suggestion and discussion with Bob. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Aug 12, 2014 at 1:29 PM, Robert Sparks wrote= : > This text would work for me. > The chairs and AD should verify it reflects consensus. > > Thanks! > > RjS > > > On 8/8/14, 8:17 AM, Bob Briscoe wrote: > > Robert, > > We're glad you found it accessible. Thank you for pointing out the > inconsistency between this, 7141 & 6789 - I (Bob) am impressed given I wa= s > a co-author of all of them and I hadn't noticed. We have suggested edits > below to remove the inconsistency, moving up the last para and adding som= e > explanatory text (unlike the original text, it is not indented). > > Ideally, RFC6789 should have said that its definition of congestion-volum= e > is applicable to today's Internet and may change. Given most RFCs only > apply to today's Internet, we don't think we need to go to the trouble of > updating 6789. So, instead, we have qualified the applicability of 6789 i= n > this document. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CURRENT: > Whether to use bytes or packets is not obvious. For instance, the > most expensive links in the Internet, in terms of cost per bit, are > all at lower data rates, where transmission times are large and > packet sizes are important. In order for a policy to consider wire > time, it needs to know the number of congested bytes. However, high > speed networking equipment and the transport protocols themselves > sometimes gauge resource consumption and congestion in terms of > packets. > > This document does not take a strong position on this issue. > However, a ConEx encoding will need to explicitly specify whether it > assumes units of bytes or packets consistently for both congestion > indications and ConEx markings (see network layer requirement E in > Section 3.3). It may help to refer to the guidance in [RFC7141]. > > [RFC7141] advises that congestion indications should be interpreted > in units of bytes when responding to congestion, at least on today's > Internet. In any TCP implementation this is simple to achieve for > varying size packets, given TCP SACK tracks losses in bytes. If an > encoding is specified in units of bytes, the encoding should also > specify which headers to include in the size of a packet (see network > layer requirement F in Section 3.3). > SUGGESTED: > Whether to use bytes or packets is not obvious. For instance, the > most expensive links in the Internet, in terms of cost per bit, are > all at lower data rates, where transmission times are large and > packet sizes are important. In order for a policy to consider wire > time, it needs to know the number of congested bytes. However, high > speed networking equipment and the transport protocols themselves > sometimes gauge resource consumption and congestion in terms of > packets. > > [RFC7141] advises that congestion indications should be interpreted > in units of bytes when responding to congestion, at least on today's > Internet. [RFC6789] takes the same view in its definition of > congestion-volume, again for today's Internet. > > In any TCP implementation this is simple to achieve for > varying size packets, given TCP SACK tracks losses in bytes. If an > encoding is specified in units of bytes, the encoding should also > specify which headers to include in the size of a packet (see network > layer requirement F in Section 3.3). > > RFC 7141 constructs an argument for why equipment tends to be built so > that the bottleneck will be the bit-carrying capacity of its interfaces n= ot > its packet processing capacity. However, RFC 7141 acknowledges that the > position may change in future, and notes that new techniques will need to > be developed to distinguish packet- and bit-congestion. > > Given this document describes an abstract ConEx mechanism, it is intended > to be timeless. Therefore it does not take a strong position on this issu= e. > However, a ConEx encoding will need to explicitly specify whether it > assumes units of bytes or packets consistently for both congestion > indications and ConEx markings (see network layer requirement E in > Section 3.3). It may help to refer to the guidance in [RFC7141]. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Regards > > > Bob Briscoe & Matt Mathis > > > On Wed, Aug 6, 2014 at 1:28 AM, Robert Sparks > wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on Gen= -ART, > please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > Please resolve these comments along with any other Last Call comments yo= u > may receive. > Document: draft-ietf-conex-abstract-mech-12 Reviewer: Robert Sparks Revi= ew > Date: 5-Aug-2014 IETF LC End Date: 8-Aug-2014 IESG Telechat date: Not on > an upcoming telechat agenda > Summary: Ready for publication as Informational > This document handles a complex description problem in a very accessible > way. Thank you for the effort that has gone into creating it. > One minor point to double-check: > This document goes out of its way to push decisions about measuring in > packets, bytes, or other units to the concrete =C3=82 encoding proposals. > RFC6789 was explicit about conex exposing a metric of congestion-volume > measured in bytes. > RFC6789 was published a couple of years ago - has that part of it become > stale? If so, it would be good for this document to explicitly call that > out. > If not, (most of section 4.6 goes back to -04 which predates RFC6789), d= oes > this document need to retain the this flexibility in its description? > > ________________________________________________________________ > Bob Briscoe, BT > > > --001a113dc36876fe050506311f82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I made one tweak relative to this change as previously agr= eed: the very last paragraph of the original section was not marked to be d= eleted but had been pulled up earlier in the section.=C2=A0 I deleted the d= uplicate text.

I also changed one word in the abstract, = per another LC suggestion and discussion with Bob.

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

Priv= acy matters!=C2=A0 We know from recent events that people are using our ser= vices to speak in defiance of unjust governments. =C2=A0 We treat privacy a= nd security as matters of life and death, because for some users, they are.=

On Tue, Aug 12, 2014 at 1:29 PM, Robert Spar= ks <rjsparks@nostrum.com> wrote:
=20 =20 =20
This text would work for me.
The chairs and AD should verify it reflects consensus.

Thanks!

RjS


On 8/8/14, 8:17 AM, Bob Briscoe wrote:
Robert,

We're glad you found it accessible. Thank you for pointing out th= e inconsistency between this, 7141 & 6789 - I (Bob) am impressed given I was a co-author of all of them and I hadn't noticed. We have suggested edits below to remove the inconsistency, moving up the last para and adding some explanatory text (unlike the original text, it is not indented).

Ideally, RFC6789 should have said that its definition of congestion-volume is applicable to today's Internet and may change. Given most RFCs only apply to today's Internet, we don't think we n= eed to go to the trouble of updating 6789. So, instead, we have qualified the applicability of 6789 in this document.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CURRENT:
=C2=A0=C2=A0 Whether to use bytes or packets is not obvious.=C2=A0 Fo= r instance, the
=C2=A0=C2=A0 most expensive links in the Internet, in terms of cost p= er bit, are
=C2=A0=C2=A0 all at lower data rates, where transmission times are la= rge and
=C2=A0=C2=A0 packet sizes are important.=C2=A0 In order for a policy = to consider wire
=C2=A0=C2=A0 time, it needs to know the number of congested bytes.=C2= =A0 However, high
=C2=A0=C2=A0 speed networking equipment and the transport protocols themselves
=C2=A0=C2=A0 sometimes gauge resource consumption and congestion in t= erms of
=C2=A0=C2=A0 packets.

=C2=A0=C2=A0 This document does not take a strong position on this issue.
=C2=A0=C2=A0 However, a ConEx encoding will need to explicitly specif= y whether it
=C2=A0=C2=A0 assumes units of bytes or packets consistently for both congestion
=C2=A0=C2=A0 indications and ConEx markings (see network layer requirement E in
=C2=A0=C2=A0 Section 3.3).=C2=A0 It may help to refer to the guidance= in [RFC7141].

=C2=A0=C2=A0 [RFC7141] advises that congestion indications should be interpreted
=C2=A0=C2=A0 in units of bytes when responding to congestion, at leas= t on today's
=C2=A0=C2=A0 Internet.=C2=A0 In any TCP implementation this is simple= to achieve for
=C2=A0=C2=A0 varying size packets, given TCP SACK tracks losses in bytes.=C2=A0 If an
=C2=A0=C2=A0 encoding is specified in units of bytes, the encoding sh= ould also
=C2=A0=C2=A0 specify which headers to include in the size of a packet (see network
=C2=A0=C2=A0 layer requirement F in Section 3.3).
SUGGESTED:
=C2=A0=C2=A0 Whether to use bytes or packets is not obvious.=C2=A0 Fo= r instance, the
=C2=A0=C2=A0 most expensive links in the Internet, in terms of cost p= er bit, are
=C2=A0=C2=A0 all at lower data rates, where transmission times are la= rge and
=C2=A0=C2=A0 packet sizes are important.=C2=A0 In order for a policy = to consider wire
=C2=A0=C2=A0 time, it needs to know the number of congested bytes.=C2= =A0 However, high
=C2=A0=C2=A0 speed networking equipment and the transport protocols themselves
=C2=A0=C2=A0 sometimes gauge resource consumption and congestion in t= erms of
=C2=A0=C2=A0 packets.

=C2=A0=C2=A0 [RFC7141] advises that congestion indications should be interpreted
=C2=A0=C2=A0 in units of bytes when responding to congestion, at leas= t on today's
=C2=A0=C2=A0 Internet.=C2=A0 [RFC6789] takes the same view in its definition of
congestion-volume, again for today's Internet.

=C2=A0=C2=A0 In any TCP implementation this is simple to achieve for<= br> =C2=A0=C2=A0 varying size packets, given TCP SACK tracks losses in bytes.=C2=A0 If an
=C2=A0=C2=A0 encoding is specified in units of bytes, the encoding sh= ould also
=C2=A0=C2=A0 specify which headers to include in the size of a packet (see network
=C2=A0=C2=A0 layer requirement F in Section 3.3).

RFC 7141 constructs an argument for why equipment tends to be built so that the bottleneck will be the bit-carrying capacity of its interfaces not its packet processing capacity. However, RFC 7141 acknowledges that the position may change in future, and notes that new techniques will need to be developed to distinguish packet- and bit-congestion.

Given this document describes an abstract ConEx mechanism, it is intended to be timeless. Therefore it does not take a strong position on this issue.
=C2=A0=C2=A0 However, a ConEx encoding will need to explicitly specif= y whether it
=C2=A0=C2=A0 assumes units of bytes or packets consistently for both congestion
=C2=A0=C2=A0 indications and ConEx markings (see network layer requirement E in
=C2=A0=C2=A0 Section 3.3).=C2=A0 It may help to refer to the guidance= in [RFC7141].
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Regards


Bob Briscoe & Matt Mathis


On Wed, Aug 6, 2014 at 1:28 AM, Robert Sparks <rjspark= s@nostrum.com> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&g= t;.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-conex-abstract-mech-12
Reviewer: Robert Sparks
Review Date: 5-Aug-2014
IETF LC End Date: 8-Aug-2014
IESG Telechat date: Not on an upcoming telechat agenda
Summary: Ready for publication as Informational
This document handles a complex description problem in a very accessible way.
Thank you for the effort that has gone into creating it.
One minor point to double-check:
This document goes out of its way to push decisions about measuring in packets,
bytes, or other units to the concrete =C3=82 encoding proposals. RFC6789 was explicit
about conex exposing a metric of congestion-volume measured in bytes.
RFC6789 was published a couple of years ago - has that part of it become stale?
If so, it would be good for this document to explicitly call that out.
If not, (most of section 4.6 goes back to -04 which predates RFC6789),
does this document need to retain the this flexibility in its description?

________________________________________________________________
Bob Briscoe,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 BT



--001a113dc36876fe050506311f82-- From nobody Mon Oct 27 11:27:33 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D991A8A88 for ; Mon, 27 Oct 2014 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXeUecLaVKfE for ; Mon, 27 Oct 2014 11:27:06 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A20A1A8F35 for ; Mon, 27 Oct 2014 11:23:43 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id m8so1764843obr.38 for ; Mon, 27 Oct 2014 11:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LbzOvUH5MUQzEwRP97NxKrOpqhxZNJzIiONWqLzwwek=; b=GFexk5T8o9HSG4KSGkbeiUSm3FRMiPTdDFBMY+Ntln1cBx5NDGnA80rKIT+llUDCmJ gwf5yncfO2o7ZwhV4Z+OI7APeLk+w36KVezotT4NYQHM7ShUnpY41nVdVyGpICcdJ9dl MaBBIazuNONU08XmpOFE9QACSZPBiS94NMRnPY4ZiYD3s4rzvVBb5T5vbFXFjVAXqEb4 0dMMx++S34IXbLmPBOTozYNE4j1BsI3jGC3+ygaPxntzrIXp2BXP4yhV0fSXS5Hk+g+W wKvvRLUYiVLqs6jbU5YkxDEYGtlAyIdkqyL8HNlkLxd+wQTK/XzqYzQuLA1KFopd2j5u fWAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LbzOvUH5MUQzEwRP97NxKrOpqhxZNJzIiONWqLzwwek=; b=WdTlSbMsNnEMfvxouMLMYRwpJcWson/9EuofL7VxAzgIttvunbmFgzB+43MLUu9UhV BFWl5fQbYTp0rEzX4ux5MVlYSwMkmpaFO0T4qT3W8xMW5O335Ivl9VcKuyfyGermyW5J ITOAEFCu6Txl18w0uPshwt5MHO+Zi6e2iv0/SNk4zLz0Y20pAG1Fy1VzPG37pYda96ZX 7orur3l4yjQ24B+brQKlOuBVQYjfxNHUGI0Dzy1ZoKFb5XEDliFyiNAOE3UH/pA9GGXd +HGtJgUchIEyshOTrRc0jujtYxmhWBsQIqbcEKStvqrwrF1yMOKq6rtZWePX3bYyvbWn K9Lg== X-Gm-Message-State: ALoCoQlKk+ADu6arBKbFRf175rD5riVRlpqiFNmwDi0rCkVuLza8fs8+U/5QhLcVut+1sOwIjjkg MIME-Version: 1.0 X-Received: by 10.60.134.20 with SMTP id pg20mr20264718oeb.36.1414434222643; Mon, 27 Oct 2014 11:23:42 -0700 (PDT) Received: by 10.182.248.161 with HTTP; Mon, 27 Oct 2014 11:23:42 -0700 (PDT) In-Reply-To: References: <54253A22.2050904@tik.ee.ethz.ch> Date: Mon, 27 Oct 2014 11:23:42 -0700 Message-ID: From: Nandita Dukkipati To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=047d7b47294866396505066ba1c6 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/qNuMsL2pdq7v3LCNNg8t7KbqYKE Cc: ConEx IETF list Subject: Re: [conex] TCP mods: Intro X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:27:08 -0000 --047d7b47294866396505066ba1c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > Would it be helpful if I add a paragraph saying: > > =E2=80=9ESection 2 provides an overview of the needed modifications for T= CP > senders to implement ConEx. > First congestion information have to be extracted from loss or ECN > feedback in TCP > as described in Section 3. Section 4 details how to set the CDO marking > based on the accounted > congestion information.=E2=80=9C > The above para is much clearer than before. Thanks. Please also include a sentence or two on the remaining Sections 5 and 6. Nandita --047d7b47294866396505066ba1c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Would it be helpful if I add a paragraph saying:

=E2=80=9ESection 2 provides an overview of the needed modifications for TCP= senders to implement ConEx.
First congestion information have to be extracted from loss or ECN feedback= in TCP
as described in Section 3. Section 4 details how to set the CDO marking bas= ed on the accounted
congestion information.=E2=80=9C

The above para is much clearer than before. Thanks. Please also inclu= de a sentence or two on the remaining Sections 5 and 6.

Nandita=C2=A0
--047d7b47294866396505066ba1c6-- From nobody Tue Oct 28 03:13:58 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644D31A1AA1 for ; Tue, 28 Oct 2014 03:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIV0WuWJYpOa for ; Tue, 28 Oct 2014 03:13:28 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D041A044F for ; Tue, 28 Oct 2014 03:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CBC5CD9305; Tue, 28 Oct 2014 11:13:26 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VFr8HdY1QPrw; Tue, 28 Oct 2014 11:13:26 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 970CDD9304; Tue, 28 Oct 2014 11:13:26 +0100 (MET) Message-ID: <544F6C46.2060705@tik.ee.ethz.ch> Date: Tue, 28 Oct 2014 11:13:26 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nandita Dukkipati References: <54253A22.2050904@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/6AyUn21af88Di5kvW-RX0dI8JkM Cc: ConEx IETF list Subject: Re: [conex] TCP mods: Intro X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 10:13:32 -0000 Hi Nandita, I've added one more sentence: "Section 5 finally discusses timeliness of the ConEx feedback signal as congestion is a temporary state." Section 6 is acknowledgements... Mirja On 27.10.2014 19:23, Nandita Dukkipati wrote: >> >> >> Would it be helpful if I add a paragraph saying: >> >> „Section 2 provides an overview of the needed modifications for TCP >> senders to implement ConEx. >> First congestion information have to be extracted from loss or ECN >> feedback in TCP >> as described in Section 3. Section 4 details how to set the CDO marking >> based on the accounted >> congestion information.“ >> > > The above para is much clearer than before. Thanks. Please also include a > sentence or two on the remaining Sections 5 and 6. > > Nandita > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Tue Oct 28 03:19:01 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02AA1A1AFC for ; Tue, 28 Oct 2014 03:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKat0aAAHuHN for ; Tue, 28 Oct 2014 03:18:17 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E161A1ADA for ; Tue, 28 Oct 2014 03:18:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2C59FD9305; Tue, 28 Oct 2014 11:18:16 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i+wrt3gvq5M9; Tue, 28 Oct 2014 11:18:15 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E810ED9304; Tue, 28 Oct 2014 11:18:15 +0100 (MET) Message-ID: <544F6D67.1040606@tik.ee.ethz.ch> Date: Tue, 28 Oct 2014 11:18:15 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: ConEx IETF list , Nandita Dukkipati Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/sYO7I3M4jckOvWehA1r8EPXs6FQ Subject: [conex] TPC mods: Sender-side Modifications X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 10:18:21 -0000 Hi Nandita, as we have agreed on the Intro, I am now sending the next section (see below). Mirja ------------------------------------------------------------------------ 2. Sender-side Modifications A ConEx sender MUST negotiate for both SACK and ECN or the more accurate ECN feedback in the TCP handshake if these TCP extension are available at the sender. Thus a ConEx SHOULD also implement SACK and ECN. Depending on the capability of the receiver, the following operation modes exist: o SACK-accECN-ConEx (SACK and accurate ECN feedback) o accECN-ConEx (no SACK but accurate ECN feedback) o ECN-ConEx (no SACK and no accurate ECN feedback but 'classic' ECN) o SACK-ECN-ConEx (SACK and 'classic' instead of accurate ECN) o SACK-ConEx (SACK but no ECN at all) o Basic-ConEx (neither SACK nor ECN) A ConEx sender MUST expose all congestion information to the network according to the congestion information received by ECN or based on loss information provided by the TCP feedback loop. A TCP sender SHOULD account congestion byte-wise (and not packet-wise). A sender MUST mark subsequent packets (after the congestion notification) with the respective ConEx bit in the IP header. Furthermore, a ConEx sender must send enough credit to cover all experienced congestion for the connection so far, as well as the risk of congestion for the current transmission (see Section 4.2. With SACK only the number of lost payload bytes is known, but not the number of packets carrying these bytes. With classic ECN only an indication is given that a marking occurred but not the exact number of payload bytes nor packets. As network congestion is usually byte- congestion [draft-briscoe-tsvwg-byte-pkt-mark], the exact number of bytes should be taken into account, if available, to make the ConEx signal as exact as possible. Detailed mechanisms for congestion accounting in each operation mode are described in the next section. Further handling of the IPv6 bits itself if congestion was accounted is described in the subsequent section afterwards. From nobody Tue Oct 28 03:20:16 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212BA1A1B02 for ; Tue, 28 Oct 2014 03:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXNxA9Sww9Bp for ; Tue, 28 Oct 2014 03:19:35 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D0D1A1AF8 for ; Tue, 28 Oct 2014 03:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EB6F0D9305; Tue, 28 Oct 2014 11:19:33 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5eR00WFgHrOD; Tue, 28 Oct 2014 11:19:33 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A0513D9304; Tue, 28 Oct 2014 11:19:33 +0100 (MET) Message-ID: <544F6DB5.6070604@tik.ee.ethz.ch> Date: Tue, 28 Oct 2014 11:19:33 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: ConEx IETF list , Nandita Dukkipati , marcelo@it.uc3m.es Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/NxYhQpQa7ItmtopMNDif852IcA8 Subject: [conex] ConEx meeting at IETF91 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 10:19:37 -0000 Hi chairs, I just saw that there is (still) a ConEx meeting slot scheduled. Will there be a meeting? Mirja From nobody Tue Oct 28 09:47:31 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197C1A9076 for ; Tue, 28 Oct 2014 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHtwTd2BoQJO for ; Tue, 28 Oct 2014 09:47:27 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF8C1A8F4C for ; Tue, 28 Oct 2014 09:40:35 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id m8so849591obr.24 for ; Tue, 28 Oct 2014 09:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UFQuXz5ZybI9TQttny3g68jFNT+1doXKHyvla/adri0=; b=Gw56g/uPZMAoVMb+WcDB653uolD6iAHU2JGItW7CuM3mE5fdPOyQeVdffZmYCTUgcr 43YSs13wyBnG5TnWgXrno7QN+txjU44xv5zROnzPuBgw1fkeieecyw/FQ6ElfJZ4DEiT ce28C7wuB0Imp9KiCq6OuNdhfg7NhDC9IiyswvAwZ/oJpkdPWtdUu7UhhfLgIugZFwmS k/ZMAH+otgQHGHAlUhaMQCQzATphm/gQ1JvZaft3LKuHntc3J02OzqcVOzl/PVdkDw+O ojbwiVD2x92E65cOvra+zc2fjX/GJK98L/mCZj1ZJacG4CaS9gzKq9dr4mRNiA67Hc17 zKfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UFQuXz5ZybI9TQttny3g68jFNT+1doXKHyvla/adri0=; b=hSlZNVAvPDCi6F313InsL/I2cc0GwonWjZJYdZq8OIAA0j8xtPnAqDRXh3J4DQzPdO mp9rP46dUoyh/F/PXI4aJXMvIKyO+iu9G6itCPrBuyLjovnBmXD5BxXBZogriGO+1f6o e1x0J6XviK2W2L3NkEnHEO/h2PLoetd47MutcrvFJgoyFu8pb2zBcWS5K5+PHy/NfGB9 kxazl43xYD1zTdQBboFitSlpT1C9uvWAyzczgopYlsvVeE56dbJ5Zj5K8kxJ2pQQqZ0X eeYFYE86jW1+6E/xadigs4j1Wi4R5jP0PSWXlr/uc0XFhpu61c95/3uGI62tHqHTLDGa 8Ppg== X-Gm-Message-State: ALoCoQkXMqXruYRvIHiWXpXb7YSTvjTmPUWAXf+JbAWyxRuQFw6wnA6BWnWccGSmspYMI5z23c1l MIME-Version: 1.0 X-Received: by 10.60.148.232 with SMTP id tv8mr1946775oeb.72.1414514434989; Tue, 28 Oct 2014 09:40:34 -0700 (PDT) Received: by 10.182.248.161 with HTTP; Tue, 28 Oct 2014 09:40:34 -0700 (PDT) In-Reply-To: <544F6C46.2060705@tik.ee.ethz.ch> References: <54253A22.2050904@tik.ee.ethz.ch> <544F6C46.2060705@tik.ee.ethz.ch> Date: Tue, 28 Oct 2014 09:40:34 -0700 Message-ID: From: Nandita Dukkipati To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=047d7b1635076d7c2e05067e4ece Archived-At: http://mailarchive.ietf.org/arch/msg/conex/6v3DS6vgCIQzFqfwp0FhkIv2soI Cc: ConEx IETF list Subject: Re: [conex] TCP mods: Intro X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:47:28 -0000 --047d7b1635076d7c2e05067e4ece Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 3:13 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Nandita, > > I've added one more sentence: > > "Section 5 finally discusses timeliness of the ConEx feedback signal as > congestion is a temporary state." > you can remove 'finally'. > > Section 6 is acknowledgements... > > Mirja > > > > On 27.10.2014 19:23, Nandita Dukkipati wrote: > >> >>> >>> Would it be helpful if I add a paragraph saying: >>> >>> =E2=80=9ESection 2 provides an overview of the needed modifications for= TCP >>> senders to implement ConEx. >>> First congestion information have to be extracted from loss or ECN >>> feedback in TCP >>> as described in Section 3. Section 4 details how to set the CDO marking >>> based on the accounted >>> congestion information.=E2=80=9C >>> >>> >> The above para is much clearer than before. Thanks. Please also include = a >> sentence or two on the remaining Sections 5 and 6. >> >> Nandita >> >> > -- > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland > > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ > --047d7b1635076d7c2e05067e4ece Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 3:13 AM, Mirja K=C3=BChlewind <mirja.kue= hlewind@tik.ee.ethz.ch> wrote:
Hi Nandita,

I've added one more sentence:

"Section 5 finally discusses timeliness of the ConEx feedback signal a= s congestion is a temporary state."
you can remov= e 'finally'.
=C2=A0

Section 6 is acknowledgements...

Mirja



On 27.10.2014 19:23, Nandita Dukkipati wrote:


Would it be helpful if I add a paragraph saying:

=E2=80=9ESection 2 provides an overview of the needed modifications for TCP=
senders to implement ConEx.
First congestion information have to be extracted from loss or ECN
feedback in TCP
as described in Section 3. Section 4 details how to set the CDO marking
based on the accounted
congestion information.=E2=80=9C


The above para is much clearer than before. Thanks. Please also include a sentence or two on the remaining Sections 5 and 6.

Nandita


--
------------------------------------------
Dipl.-Ing. Mirja K=C3=BChlewind
Communication Systems Group
Institute TIK, ETH Z=C3=BCrich
Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------

--047d7b1635076d7c2e05067e4ece--