From nobody Tue Aug 5 12:58: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 B53B01A02B9; Tue, 5 Aug 2014 12:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 lxo09YOQlIvx; Tue, 5 Aug 2014 12:58:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501861A028B; Tue, 5 Aug 2014 12:58:52 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s75Jwpvl096793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 5 Aug 2014 14:58:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53E1377A.5010906@nostrum.com> Date: Tue, 05 Aug 2014 14:58:50 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: General Area Review Team , conex@ietf.org, "ietf@ietf.org" , draft-ietf-conex-abstract-mech.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/dv3K-n1f2AEP43QIZzwBSUffCBo Subject: [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: Tue, 05 Aug 2014 19:58:53 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . 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 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? From nobody Wed Aug 6 17:02:35 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 978C81A02E6 for ; Wed, 6 Aug 2014 17:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 dhwC7ogDsISk for ; Wed, 6 Aug 2014 17:02:30 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B101B2886 for ; Wed, 6 Aug 2014 17:02:30 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id wp4so2373044obc.29 for ; Wed, 06 Aug 2014 17:02:29 -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=YhHpVIVU32CgKXxp2h+FjEauKu96TPfmUi9yjNQL8g4=; b=KcFuN//fVYcN9eaM5UR/5gWto79h2O2JY2RK7yK6fHtJlRo+qSkTE2xUWwUtyvHH6L sicdLBWmbWn5Xnkh9zkf8krHoiGcIe1b+PVBGczOiS3MfpnD+YXSURGj8MNFBWteaN4J v4LQw112G9JJWJ7Bly7+rjLl2GRRdSmNDYnkzLko7AuzMY21h2b8tvNqCU3mfCCJWGqC BCITMe5v0UXg+S3h+do7Ed20Da8k8ttZ1QWIgNO688cA5zYSbmjWngZ0KPW7VwD7OrfU gBu/ISAEnq7zC0+cmQ6CYuNuoNjtD6YaIESecxihKCaD/JrmguslmBhWf2YDUblLzwpB D8Bg== 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=YhHpVIVU32CgKXxp2h+FjEauKu96TPfmUi9yjNQL8g4=; b=BFj05H5eTZhfLO6EoyBltAeyjYLTYSxD/4FCfxaj4cWuw1DOWGwZ6sj4b4W8oZ3pFg 2i2SuZPBnnckg8MFNSq0lu8qiT9zhIZaAY1XGuG3XQ55ooYJ8RcEmHFNHPjw4LIfje60 AOk7sTFY3+NTjGaQ5BbddBkNaTFTj+T+K1E7MvCI2qNz3shrxXz4ED8MKtGB2Wro3CdC MOx16QRmQfmdo8Hbq4Y8U9COUnAziygpUohv5J77HY0N2Rd0fTAJ/xyEM3CD3Lo3LbmT 77dB3LxirohMQWgs9pxRdbT3tlhKYrkFICN3CklOtDv8ypsAqfsh9KIFRrwtz8MEqVg2 tHaA== X-Gm-Message-State: ALoCoQkSZF0s00YvOCVhA5wGj/Th0Z42ilDpXe5SBN4xTYlDJgexMnHYozaBjCTUArsb83S59P8N MIME-Version: 1.0 X-Received: by 10.182.113.199 with SMTP id ja7mr18911330obb.74.1407369749694; Wed, 06 Aug 2014 17:02:29 -0700 (PDT) Received: by 10.182.18.145 with HTTP; Wed, 6 Aug 2014 17:02:29 -0700 (PDT) In-Reply-To: <53E1377A.5010906@nostrum.com> References: <53E1377A.5010906@nostrum.com> Date: Wed, 6 Aug 2014 17:02:29 -0700 Message-ID: From: Matt Mathis To: Robert Sparks Content-Type: multipart/alternative; boundary=089e012954dcffb32a04fffecded Archived-At: http://mailarchive.ietf.org/arch/msg/conex/O_GwikfFNL3mnFmPXRz0IN78KpM Cc: General Area Review Team , "ietf@ietf.org" , draft-ietf-conex-abstract-mech.all@tools.ietf.org, ConEx IETF list 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: Thu, 07 Aug 2014 00:02:32 -0000 --089e012954dcffb32a04fffecded Content-Type: text/plain; charset=UTF-8 You are correct, the section is a bit stale. And although the authors of 6789 would like to claim the topic is closed, newer documents (e.g. draft-ietf-tcpm-accecn-reqs-07.txt,) have found it necessary to hedge on this very issue for pragmatic reasons. (Note the overlapping authors between -abstract-mech-, 6789 and -accecn-). The core advice in section 4.6 still stands: > > "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)." Some of the surrounding editorializing reflects not completely resolved tension between the authors on this point. I for one would prefer to remove the presumption that 6789 and 7141 are the final answer, and make this draft purely bytes/packets agnostic. I partially ceded the point on the grounds that the impracticality 6789 would doom it over the long haul, as we have already seen in -accecn-. It would be bad form for this document to explicitly conflict with 6789, but I for one would object to it unequivocally endorsing 6789, and although leaving it waffle, isn't pretty, it does accurately reflect the views of the authors. 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 5, 2014 at 12:58 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > 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 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? > > --089e012954dcffb32a04fffecded Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You are correct, the section is a bit stale. =C2=A0And alt= hough the authors of 6789 would like to claim the topic is closed, newer do= cuments (e.g.=C2=A0draft-ietf-tcpm-accecn-reqs-07.txt,) have found it neces= sary to hedge on this very issue for pragmatic reasons. =C2=A0(Note the ove= rlapping authors between -abstract-mech-, 6789 and=C2=A0-accecn-).

The core advice in section 4.6 still stands:=C2=A0 "This document does not take a strong position on this issue. =C2=A0 = =C2=A0However, a ConEx encoding will need to explicitly specify whether it = assumes units of bytes or packets consistently for both congestion indicati= ons and ConEx markings. =C2=A0(see network layer requirement E in=C2= =A0Section 3.3)."
=C2=A0
Some of the surrounding editorializing reflects not c= ompletely resolved tension between the authors on this point. =C2=A0I for o= ne would prefer to remove the presumption that=C2=A06789 and 7141 are the f= inal answer, and make this draft purely bytes/packets agnostic. =C2=A0I par= tially ceded the point on the grounds that the impracticality 6789 would do= om it over the long haul, as we have already seen in=C2=A0-accecn-.

It would be bad form for this document to explici= tly conflict with 6789, but I for one would object to it unequivocally endo= rsing 6789, and although leaving it waffle, isn't pretty, it does accur= ately reflect the views of the authors.

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

Privacy matters! =C2=A0We know from recent events that pe= ople are using our services to speak in defiance of unjust governments. =C2= =A0 We treat privacy and security as matters of life and death, because for= some users, they are.


On Tue, Aug 5, 2014 at 12:58 PM, Robert = Sparks <rjsparks@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/GenArtf= aq>.

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 wa= y.
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 pack= ets,
bytes, or other units to the concrete =C2=A0encoding 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 st= ale?
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?<= br>

--089e012954dcffb32a04fffecded-- From nobody Thu Aug 7 01:51:22 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 887A61B2A0F; Thu, 7 Aug 2014 01:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 gdcG0xTFvFrX; Thu, 7 Aug 2014 01:51:17 -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 7E0441B29FE; Thu, 7 Aug 2014 01:51:16 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Aug 2014 09:51:15 +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; Thu, 7 Aug 2014 09:51:13 +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; Thu, 7 Aug 2014 09:51:11 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.132.50]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s778p8CT002466; Thu, 7 Aug 2014 09:51:09 +0100 Message-ID: <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 7 Aug 2014 09:51:08 +0100 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <53E1377A.5010906@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_159965219==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/Lza8FVwDf7FVyrgyDJxTcmCKq6M Cc: General Area Review Team , ConEx IETF list , "ietf@ietf.org" , draft-ietf-conex-abstract-mech.all@tools.ietf.org, Robert Sparks 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: Thu, 07 Aug 2014 08:51:20 -0000 --=====================_159965219==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Matt, I've sent suggested text to you for agreement before sending to Robert. The issue with draft-kuehlewind-tcpm-accurate-ecn=20 is different. We took the (interim) decision to=20 use packets not bytes for feedback on the basis=20 that the sender could then approximately=20 reconstruct bytes if it needed to (because the=20 sender can remember the sizes of the packets it=20 sent). I say 'interim', because once we do the=20 implementation, we will see how possible this is.=20 I'm confident we can have a crack at it Linux.=20 However, I wouldn't even want to attempt it in=20 FreeBSD, which doesn't keep a record of packets=20 in flight, so it would require a complete redesign. You may be basing your view on the accecn=20 presentation I gave, which was brief on this=20 point. In the accecn draft it says: " If a particular sender behaviour needed to associate AccECN's feedback of each ECN marking with the size of the original packet that picked up the marking, there is enough information in AccECN feedback to do so, although perhaps imperfectly. ... ...to apply AccECN to these more challenging tasks, the Data Sender would probably have to record the sizes and/or timings of packets in flight and combine AccECN feedback with the cumulative acknowledgement numbers on each ACK as well as selective ACK (SACK) information [RFC2018]. " Bob At 01:02 07/08/2014, Matt Mathis wrote: >You are correct, the section is a bit stale. =C2=20 >And although the authors of 6789 would like to=20 >claim the topic is closed, newer documents=20 >(e.g.=C2 draft-ietf-tcpm-accecn-reqs-07.txt,) have=20 >found it necessary to hedge on this very issue=20 >for pragmatic reasons. =C2 (Note the overlapping=20 >authors between -abstract-mech-, 6789 and=C2 -accecn-). > >The core advice in section 4.6 still stands:=C2 >"This document does not take a strong position=20 >on this issue. =C2 =C2 However, a ConEx encoding=20 >will need to explicitly specify whether it=20 >assumes units of bytes or packets consistently=20 >for both congestion indications and ConEx=20 >markings. =C2 (see network layer requirement E in=C2 Section 3.3)." > >=C2 >Some of the surrounding editorializing reflects=20 >not completely resolved tension between the=20 >authors on this point. =C2 I for one would prefer=20 >to remove the presumption that=C2 6789 and 7141=20 >are the final answer, and make this draft purely=20 >bytes/packets agnostic. =C2 I partially ceded the=20 >point on the grounds that the impracticality=20 >6789 would doom it over the long haul, as we have already seen in=C2= -accecn-. > >It would be bad form for this document to=20 >explicitly conflict with 6789, but I for one=20 >would object to it unequivocally endorsing 6789,=20 >and although leaving it waffle, isn't pretty, it=20 >does accurately reflect the views of the authors. > >Thanks, >--MM-- >The best way to predict the future is to create it. =C2 - Alan Kay > >Privacy matters! =C2 We know from recent events=20 >that people are using our services to speak in=20 >defiance of unjust governments. =C2 We treat=20 >privacy and security as matters of life and=20 >death, because for some users, they are. > > >On Tue, Aug 5, 2014 at 12:58 PM, Robert Sparks=20 ><rjsparks@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>. > >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=20 >decisions about measuring in packets, >bytes, or other units to the concrete =C2 encoding=20 >proposals. RFC6789 was explicit >about conex exposing a metric of congestion-volume measured in bytes. > >RFC6789 was published a couple of years ago -=20 >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, BT=20 --=====================_159965219==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt,

I've sent suggested text to you for agreement before sending to Robert.

The issue with draft-kuehlewind-tcpm-accurate-ecn is different. We took the (interim) decision to use packets not bytes for feedback on the basis that the sender could then approximately reconstruct bytes if it needed to (because the sender can remember the sizes of the packets it sent). I say 'interim', because once we do the implementation, we will see how possible this is. I'm confident we can have a crack at it Linux. However, I wouldn't even want to attempt it in FreeBSD, which doesn't keep a record of packets in flight, so it would require a complete redesign.

You may be basing your view on the accecn presentation I gave, which was brief on this point. In the accecn draft it says:

"   If a particular sender behaviour needed to associate AccECN's
   feedback of each ECN marking with the size of the original packet
   that picked up the marking, there is enough information in AccECN
   feedback to do so, although perhaps imperfectly.  ...

            &nbs= p;            &n= bsp;            =            ...to apply AccECN to
   these more challenging tasks, the Data Sender would probably have to
   record the sizes and/or timings of packets in flight and combine
   AccECN feedback with the cumulative acknowledgement numbers on each
   ACK as well as selective ACK (SACK) information [RFC2018].
"


Bob

At 01:02 07/08/2014, Matt Mathis wrote:
You are correct, the section = is a bit stale. =C2 And although the authors of 6789 would like to claim the topic is closed, newer documents (e.g.=C2 draft-ietf-tcpm-accecn-reqs-07.txt,) have found it necessary to hedge on this very issue for pragmatic reasons. =C2 (Note the overlapping authors between -abstract-mech-, 6789 and=C2 -accecn-).

The core advice in section 4.6 still stands:=C2
"This document does not take a strong position on this issue. =C2  =C2 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. =C2 (see network layer requirement E in=C2 Section 3.3)."

=C2
Some of the surrounding editorializing reflects not completely resolved tension between the authors on this point. =C2 I for one would prefer to remove the presumption that=C2 6789 and 7141 are the final answer, and make this draft purely bytes/packets agnostic. =C2 I partially ceded the point on the grounds that the impracticality 6789 would doom it over the long haul, as we have already seen in=C2 -accecn-.

It would be bad form for this document to explicitly conflict with 6789, but I for one would object to it unequivocally endorsing 6789, and although leaving it waffle, isn't pretty, it does accurately reflect the views of the authors.

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

Privacy matters! =C2 We know from recent events that people are using our services to speak in defiance of unjust governments. =C2  We treat privacy and security as matters of life and death, because for some users, they are.


On Tue, Aug 5, 2014 at 12:58 PM, Robert Sparks <rjsparks@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>.

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 =C2 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,           &n= bsp;            =             &nbs= p;             BT --=====================_159965219==.ALT-- From nobody Thu Aug 7 05:01:19 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 941C21B2A80; Thu, 7 Aug 2014 05:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 JyRny_ZJeH2o; Thu, 7 Aug 2014 05:01:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F033A1ABB23; Thu, 7 Aug 2014 05:01:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3C3FFC94A8; Thu, 7 Aug 2014 08:01:10 -0400 (EDT) Date: Thu, 7 Aug 2014 08:01:10 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140807120110.GA81408@verdi> References: <53E1377A.5010906@nostrum.com> <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/conex/bCHOVFRXwPlYJaqyCit6Uj1BbTI Cc: Robert Sparks , "ietf@ietf.org" , ConEx IETF list 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: Thu, 07 Aug 2014 12:01:16 -0000 Bob Briscoe wrote: > > Matt, > > I've sent suggested text to you for agreement before sending to Robert. That sentence unwittingly summarizes the story of ConEx: Bob wants the authors to do the work, not the WG. :^( This is very sad. Bob is an extremely intelligent fellow with lots of good ideas; but he's very selective in who he works with. ConEx is a story of Bob abandoning co-authors when they questioned him too much. I, for example, was purged when I pointed that accurately counting packets had to be better than under-counting bytes, and that there were significant areas of the Internet which are not simply byte-congestible. Apparently Bob is getting ready to purge Matt Mathis. :^( :^( > The issue with draft-kuehlewind-tcpm-accurate-ecn > is different. We took the (interim) decision to > use packets not bytes for feedback on the basis > that the sender could then approximately > reconstruct bytes if it needed to (because the > sender can remember the sizes of the packets it > sent)... Note the "we". In fact, ECN feedback _has_ to reflect packets. All the noise about what senders "could" do is just rationalizing. :^( > At 01:02 07/08/2014, Matt Mathis wrote: > >> You are correct, the section is a bit stale. >> And although the authors of 6789 would like to >> claim the topic is closed, newer documents >> (e.g.? draft-ietf-tcpm-accecn-reqs-07.txt,) have >> found it necessary to hedge on this very issue >> for pragmatic reasons. ? (Note the overlapping >> authors between -abstract-mech-, 6789 and? -accecn-). I respect Matt: thus when he asked me to stop posting about bytes vs. packets, I did... >> The core advice in section 4.6 still stands:? >> "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)." Technically, it is possible for some future transport to use ECN and count bytes instead of packets: I remain unconvinced that this could ever _accurately_ count bytes-on-the-wire (which is what byte-congestible _means_). >> Some of the surrounding editorializing reflects >> not completely resolved tension between the >> authors on this point. ? I for one would prefer >> to remove the presumption that? 6789 and 7141 >> are the final answer, and make this draft purely >> bytes/packets agnostic. ? I partially ceded the >> point on the grounds that the impracticality >> 6789 would doom it over the long haul, as we have already seen in? >> -accecn-. I'm afraid it's not only 6789 that's doomed. ConEx is very likely to be shut down entirely. Right now we're being told to get on schedule; but in essence we _can't_ stay on schedule: thus the question is whether we'll get this draft to the IESG before we're shut down, not _whether_ we'll be shut down. :^( >> It would be bad form for this document to >> explicitly conflict with 6789, but I for one >> would object to it unequivocally endorsing 6789, >> and although leaving it waffle, isn't pretty, it >> does accurately reflect the views of the authors. I would still like ConEx to produce a practical system for making congestion visible within the routing cloud. I don't see any way for that to happen. Thus, I simply support Matt on this question. -- John Leslie From nobody Thu Aug 7 07:34:08 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 8AEE31B2B87; Thu, 7 Aug 2014 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 ZQ2lvUI_Soha; Thu, 7 Aug 2014 07:33:56 -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 888B41B2B88; Thu, 7 Aug 2014 07:33:45 -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; Thu, 7 Aug 2014 15:33:44 +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; Thu, 7 Aug 2014 15:33:40 +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; Thu, 7 Aug 2014 15:33:39 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.160.55]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s77EXanZ003403; Thu, 7 Aug 2014 15:33:36 +0100 Message-ID: <201408071433.s77EXanZ003403@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 7 Aug 2014 15:33:36 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20140807120110.GA81408@verdi> References: <53E1377A.5010906@nostrum.com> <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> <20140807120110.GA81408@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/nRg6GOZYPb-pocLh_HHWm8ZgQho Cc: Robert Sparks , "ietf@ietf.org" , ConEx IETF list 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: Thu, 07 Aug 2014 14:34:06 -0000 John, Please write your arguments down about byte-pkt in an Internet Draft. Then if you have a coherent argument, we will all be able to understand it. I cannot understand what your arguments are in all the emails you have sent on this subject; too much seems to be implied rather than stated. More inline... At 13:01 07/08/2014, John Leslie wrote: >Bob Briscoe wrote: > > > > Matt, > > > > I've sent suggested text to you for agreement before sending to Robert. > > That sentence unwittingly summarizes the story of ConEx: Bob wants >the authors to do the work, not the WG. :^( > > This is very sad. Bob is an extremely intelligent fellow with lots >of good ideas; but he's very selective in who he works with. ConEx is >a story of Bob abandoning co-authors when they questioned him too much. > > I, for example, was purged when I pointed that accurately counting >packets had to be better than under-counting bytes, and that there were >significant areas of the Internet which are not simply byte-congestible. In case anyone on the list interprets John's use of the passive ("I was purged") as implying I somehow removed him, I didn't. The decision was presented to me by the chairs just as it was presented to John. Although I don't fully know the reasons, I doubt very much that it was anything to do something as specific as byte-pkt arguments. > Apparently Bob is getting ready to purge Matt Mathis. :^( :^( Why would I be talking offlist with Matt if it was my intention to purge him? Everyone works off-list with their co-authors. I primarily talk off-list to keep the signal to noise ratio high for postings on list. > > The issue with draft-kuehlewind-tcpm-accurate-ecn > > is different. We took the (interim) decision to > > use packets not bytes for feedback on the basis > > that the sender could then approximately > > reconstruct bytes if it needed to (because the > > sender can remember the sizes of the packets it > > sent)... > > Note the "we". We = the co-authors (myself, Richard Scheffenegger and Mirja Kuehlewind). We (obviously) had a huge amount of off-list discussion before posting the lastest accecn draft. We put our rationale in the draft, and now we've published it for review and comment by the whole WG. Nothing unusual about any of that. > In fact, ECN feedback _has_ to reflect packets. All the noise about >what senders "could" do is just rationalizing. :^( Not so, on both counts. 1) In accecn (so far), we could have reflected bytes counts (as TCP does with seq nos & ack nos). We chose to feedback marked packets because it should be sufficient to be interpreted either as bytes or packets - on the same basis that an ECN marking at the IP layer can be interpreted as either the bytes in the marked packets, or the number of marked packets. This also kept header overhead low enough to fit within existing fields by overloading - an attempt to minimise the chance of being tampered with by middleboxes. 2) I deferred to Mirja & Richard for determining what senders could do, given their respective expertise in Linux & FreeBSD implementations. > > At 01:02 07/08/2014, Matt Mathis wrote: > > > >> You are correct, the section is a bit stale. > >> And although the authors of 6789 would like to > >> claim the topic is closed, newer documents > >> (e.g.? draft-ietf-tcpm-accecn-reqs-07.txt,) have > >> found it necessary to hedge on this very issue > >> for pragmatic reasons. ? (Note the overlapping > >> authors between -abstract-mech-, 6789 and? -accecn-). > > I respect Matt: thus when he asked me to stop posting about bytes >vs. packets, I did... > > >> The core advice in section 4.6 still stands:? > >> "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)." > > Technically, it is possible for some future transport to use ECN >and count bytes instead of packets: I remain unconvinced that this >could ever _accurately_ count bytes-on-the-wire (which is what >byte-congestible _means_). What's the problem? If an ECN mark is interpreted in bytes, you just add up the sizes of the marked packets, rather than counting just the number of marked packets. Or is your concern about which headers were on the packet when it was marked, that may have been stripped before they reach the transport? If that is your only concern, then we will have made progress. This is something I have dismissed as an approximation error, particularly given congestion counts are universally normalised into proportions (marked vs total bytes, or marked vs total packets), and in general all the packets will have had the same headers stripped. > >> Some of the surrounding editorializing reflects > >> not completely resolved tension between the > >> authors on this point. ? I for one would prefer > >> to remove the presumption that? 6789 and 7141 > >> are the final answer, and make this draft purely > >> bytes/packets agnostic. ? I partially ceded the > >> point on the grounds that the impracticality > >> 6789 would doom it over the long haul, as we have already seen in? > >> -accecn-. > > I'm afraid it's not only 6789 that's doomed. ConEx is very likely >to be shut down entirely. Right now we're being told to get on schedule; >but in essence we _can't_ stay on schedule: thus the question is whether >we'll get this draft to the IESG before we're shut down, not _whether_ >we'll be shut down. :^( Constructive comment? > >> It would be bad form for this document to > >> explicitly conflict with 6789, but I for one > >> would object to it unequivocally endorsing 6789, > >> and although leaving it waffle, isn't pretty, it > >> does accurately reflect the views of the authors. > > I would still like ConEx to produce a practical system for making >congestion visible within the routing cloud. I don't see any way for >that to happen. Thus, I simply support Matt on this question. So do I. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT From nobody Thu Aug 7 11:10:17 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 017BF1A0292 for ; Thu, 7 Aug 2014 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URG_BIZ=0.573] 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 yW9vWlCzY09L for ; Thu, 7 Aug 2014 11:10:13 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 73F6D1A034B for ; Thu, 7 Aug 2014 11:10:12 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B3B96C94BE; Thu, 7 Aug 2014 14:10:09 -0400 (EDT) Date: Thu, 7 Aug 2014 14:10:09 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20140807181009.GB45982@verdi> References: <53E1377A.5010906@nostrum.com> <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> <20140807120110.GA81408@verdi> <201408071433.s77EXanZ003403@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201408071433.s77EXanZ003403@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/conex/mLuZWIeV_vQewFFNBMyAIr61BA4 Cc: ConEx IETF list 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: Thu, 07 Aug 2014 18:10:16 -0000 Bob Briscoe wrote: > > John, > > Please write your arguments down about byte-pkt in an Internet Draft. I suppose I'm willing to do that; but I'd much prefer not to make an Internet-Draft simply to document an argument between Bob and me. > Then if you have a coherent argument, we will all be able to > understand it. I cannot understand what your arguments are in all the > emails you have sent on this subject; too much seems to be implied > rather than stated. Let's try a summary: Beyond question, it is possible for a forwarding node to count the packets it marks or drops. While it is possible for a forwarding node to count bytes-on-the- wire for packets it marks or drops, that count may not agree with such a count at another forwarding node; and certainly will not agree with a count of payload bytes at one end or the other. It is the bytes-on-the-wire which count toward congestion; and in fact there is always _some_ per-packet overhead (though this can be rather small near the backbone -- it is _not_ small in DOCSIS cable modems). Tunnels are found in the forwarding cloud -- bytes-on-the-wire for these is greater than a non-tunnel forwarder will see. Thus, I claim it rather likely that any way endpoints might count bytes is in danger of under-counting the actual congestion. I have also claimed that so long as we're dealing in 1500-byte packets, the difference between "small" packets and "full" packets (in bytes-on-the-wire) is not great enough to justify the effort we've been putting into trying to count bytes of congestion. And in practice, most transports send similar-length packets most of the time... > At 13:01 07/08/2014, John Leslie wrote: >> >> I, for example, was purged when I pointed that accurately counting >> packets had to be better than under-counting bytes, and that there were >> significant areas of the Internet which are not simply byte-congestible. > > In case anyone on the list interprets John's use of the passive ("I > was purged") as implying I somehow removed him, I didn't. Passive voice _implies_ only that the writer didn't want to blame a particular person. I trust our readers to know this. > The decision was presented to me by the chairs just as it was presented > to John. Although I don't fully know the reasons, I doubt very much > that it was anything to do something as specific as byte-pkt arguments. That wasn't implied either... But perhaps we _do_ need to review that decision. :^( Usually I'd sleep on it before saying things like this; but I do think there's something wrong with removing two principal editors without the principal author knowing the reasons. Do either of our WGCs want to comment on _that_? >> Apparently Bob is getting ready to purge Matt Mathis. :^( :^( Appearances _can_ be misleading, I admit... > Why would I be talking offlist with Matt if it was my intention to purge > him? True, that is not Bob's normal style. > Everyone works off-list with their co-authors. I primarily talk > off-list to keep the signal to noise ratio high for postings on list. This isn't always best. The list has become near-dormant, IMHO, because folks couldn't follow the reasoning behind announced changes to the text. (I have some reason to believe even the _authors_ sometimes couldn't follow these.) > We (obviously) had a huge amount of off-list discussion before > posting the lastest accecn draft. We put our rationale in the draft, > and now we've published it for review and comment by the whole WG. > Nothing unusual about any of that. I haven't yen decided whether it's worth-while commenting on accecn. If I do, I'll mention that the complexity of Bob's "urgent pointer" proposal is a potentially serious drawback... >> In fact, ECN feedback _has_ to reflect packets. All the noise about >> what senders "could" do is just rationalizing. :^( > > Not so, on both counts. > 1) In accecn (so far), we could have reflected bytes counts (as TCP > does with seq nos & ack nos). Indeed, with a much longer TCP option, Bob could have proposed counters for payload bytes. Need I remind anyone that payload bytes is always less than bytes-on-the-wire? > We chose to feedback marked packets because it should be sufficient > to be interpreted either as bytes or packets - on the same basis that > an ECN marking at the IP layer can be interpreted as either the bytes > in the marked packets, or the number of marked packets. This also kept > header overhead low enough to fit within existing fields by overloading > - an attempt to minimise the chance of being tampered with by > middleboxes. Frankly, this still sounds like rationalizing to me, but YMMV. > 2) I deferred to Mirja & Richard for determining what senders could > do, given their respective expertise in Linux & FreeBSD > implementations. Thank you. >> Technically, it is possible for some future transport to use ECN >> and count bytes instead of packets: I remain unconvinced that this >> could ever _accurately_ count bytes-on-the-wire (which is what >> byte-congestible _means_). > > What's the problem? If an ECN mark is interpreted in bytes, you just > add up the sizes of the marked packets, rather than counting just the > number of marked packets. Alas, Bob has always been a bit vague about what exactly he counts when he counts bytes. Neither the sender nor the receiver can know what the overhead is in terms of bytes-on-the-wire. In some cases they can't even agree on the size of the packet as sent or received. I have usually guessed that Bob wishes to count payload bytes -- on which the sender and receiver _can_ agree. This, of course, would seriously under-count bytes-on-the-wire for small packets. If Bob instead wants to count total-bytes-in-the-sent-packet, it would help if he defined _how_ he wants to calculate that. (Any way he might choose, though, will under-count bytes in some cases or over-count bytes in most cases.) > Or is your concern about which headers were on the packet when it > was marked, that may have been stripped before they reach the > transport? That, I suppose, is a small part of my concern... > If that is your only concern, then we will have made progress. This > is something I have dismissed as an approximation error, particularly > given congestion counts are universally normalised into proportions > (marked vs total bytes, or marked vs total packets), and in general > all the packets will have had the same headers stripped. If I were happy to dismiss approximation errors, I would have pointed out that in practice approximating bytes by counting exactly one byte per packet (or choose any other constant number) doesn't work that badly in practice. Approximation errors aren't always small; and they often tend to go in the same direction, which becomes significant over time... >> I'm afraid it's not only 6789 that's doomed. ConEx is very likely >> to be shut down entirely. Right now we're being told to get on schedule; >> but in essence we _can't_ stay on schedule: thus the question is whether >> we'll get this draft to the IESG before we're shut down, not _whether_ >> we'll be shut down. :^( > > Constructive comment? I'd be happy to hear suggestions on how to restate that as such... >> I would still like ConEx to produce a practical system for making >> congestion visible within the routing cloud. I don't see any way for >> that to happen. Thus, I simply support Matt on this question. > > So do I. Perhaps there _is_ hope -- but I'm not fully convinced. :^( -- John Leslie From nobody Fri Aug 8 06:17:57 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 53B251B2BD0; Fri, 8 Aug 2014 06:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 kXTB1Y9uIAiH; Fri, 8 Aug 2014 06:17:46 -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 F06511B2BB0; Fri, 8 Aug 2014 06:17:45 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 8 Aug 2014 14:17:43 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 8 Aug 2014 14:17:40 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Fri, 8 Aug 2014 14:17:35 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s78DHX8w006624; Fri, 8 Aug 2014 14:17:33 +0100 Message-ID: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 8 Aug 2014 14:17:33 +0100 To: Robert Sparks From: Bob Briscoe MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_262349439==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/oHczDdPm_dJLw6MZpS6Ssv9YKI8 Cc: "ietf@ietf.org" , General Area Review Team , conex@ietf.org, 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, 08 Aug 2014 13:17:54 -0000 --=====================_262349439==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Robert, We're glad you found it accessible. Thank you for=20 pointing out the inconsistency between this, 7141=20 & 6789 - I (Bob) am impressed given I was a=20 co-author of all of them and I hadn't noticed. We=20 have suggested edits below to remove the=20 inconsistency, moving up the last para and adding=20 some explanatory text (unlike the original text, it is not indented). Ideally, RFC6789 should have said that its=20 definition of congestion-volume is applicable to=20 today's Internet and may change. Given most RFCs=20 only apply to today's Internet, we don't think we=20 need to go to the trouble of updating 6789. So,=20 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: 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=20 tends to be built so that the bottleneck will be=20 the bit-carrying capacity of its interfaces not=20 its packet processing capacity. However, RFC 7141=20 acknowledges that the position may change in=20 future, and notes that new techniques will need=20 to be developed to distinguish packet- and bit-congestion. Given this document describes an abstract ConEx=20 mechanism, it is intended to be timeless.=20 Therefore it 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]. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=20 <rjsparks@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>. >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=20 >decisions about measuring in packets, >bytes, or other units to the concrete =C2 encoding=20 >proposals. RFC6789 was explicit >about conex exposing a metric of congestion-volume measured in bytes. >RFC6789 was published a couple of years ago -=20 >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, BT =20 --=====================_262349439==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 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 need 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:
   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 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.
   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 <rjsparks@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>.
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 =C2 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,           &n= bsp;            =             &nbs= p;             BT --=====================_262349439==.ALT-- From nobody Fri Aug 8 06:50:35 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 3BCF91B2A11 for ; Fri, 8 Aug 2014 06:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URG_BIZ=0.573] 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 CgWiXlUNqyXg for ; Fri, 8 Aug 2014 06:50:30 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F0B1B299C for ; Fri, 8 Aug 2014 06:50:30 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 8 Aug 2014 14:50:24 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 8 Aug 2014 14:50:27 +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; Fri, 8 Aug 2014 14:50:26 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s78DoP4i006720; Fri, 8 Aug 2014 14:50:25 +0100 Message-ID: <201408081350.s78DoP4i006720@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 8 Aug 2014 14:50:25 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20140807181009.GB45982@verdi> References: <53E1377A.5010906@nostrum.com> <201408070851.s778p8CT002466@bagheera.jungle.bt.co.uk> <20140807120110.GA81408@verdi> <201408071433.s77EXanZ003403@bagheera.jungle.bt.co.uk> <20140807181009.GB45982@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/JtneYD8H53OW0EgQ1m9lYgymQ7M Cc: ConEx IETF list 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, 08 Aug 2014 13:50:34 -0000 John, So your argument does seem to be about not being able to allow for the bytes in headers on the wire (which the endpoints cannot guess). But you seem to have reserved the right to have other arguments. That's why it would be good to see all your arguments in a draft. The conex docs have defined their solution to this problem precisely. Specifically across these two docs: An experimental ConEx specification SHOULD describe the following protocol details: F. If the units are bytes a definition of which headers are included in the size of the packet; the number of bytes carried by this IP packet (including the IP header) SHOULD be accounted for determining congestion or credit information. Bear in mind I have as much desire for ConEx to work as you. What would be the point of me definining something I didn't think would work? Given these definitions, here are my arguments for why the missing headers problem can be considered a non-problem: 1) The quantity of congestion-bytes is primarily important at policy devices and audit. 1a) Audit: Always solely compares packets with others in the same flow, so any additional headers will be the same for both sides of the comparison. 1b) Policing: If policers work in units based on a universally measureable definition (as above), it is hardly important that the actual amount of congestion generated was from a link where there were more tunnel headers or a different link-layer - because the two never have to be directly compared or related. 2) The number of additional headers that a network path adds outside the outermost e2e IP header during transit is not something that end-systems have control over. So they should not be held responsible for them anyway (and by argument 1 there is no reason to have to). If a network operator adds so many headers that it congests its links, well frankly it should be allowed to go bust. Bob At 19:10 07/08/2014, John Leslie wrote: >Bob Briscoe wrote: > > > > John, > > > > Please write your arguments down about byte-pkt in an Internet Draft. > > I suppose I'm willing to do that; but I'd much prefer not to make >an Internet-Draft simply to document an argument between Bob and me. > > > Then if you have a coherent argument, we will all be able to > > understand it. I cannot understand what your arguments are in all the > > emails you have sent on this subject; too much seems to be implied > > rather than stated. > > Let's try a summary: > > Beyond question, it is possible for a forwarding node to count the >packets it marks or drops. > > While it is possible for a forwarding node to count bytes-on-the- >wire for packets it marks or drops, that count may not agree with such >a count at another forwarding node; and certainly will not agree with >a count of payload bytes at one end or the other. > > It is the bytes-on-the-wire which count toward congestion; and in >fact there is always _some_ per-packet overhead (though this can be >rather small near the backbone -- it is _not_ small in DOCSIS cable >modems). > > Tunnels are found in the forwarding cloud -- bytes-on-the-wire >for these is greater than a non-tunnel forwarder will see. > > Thus, I claim it rather likely that any way endpoints might count >bytes is in danger of under-counting the actual congestion. > > I have also claimed that so long as we're dealing in 1500-byte >packets, the difference between "small" packets and "full" packets >(in bytes-on-the-wire) is not great enough to justify the effort >we've been putting into trying to count bytes of congestion. > > And in practice, most transports send similar-length packets >most of the time... > > > At 13:01 07/08/2014, John Leslie wrote: > >> > >> I, for example, was purged when I pointed that accurately counting > >> packets had to be better than under-counting bytes, and that there were > >> significant areas of the Internet which are not simply byte-congestible. > > > > In case anyone on the list interprets John's use of the passive ("I > > was purged") as implying I somehow removed him, I didn't. > > Passive voice _implies_ only that the writer didn't want to blame >a particular person. I trust our readers to know this. > > > The decision was presented to me by the chairs just as it was presented > > to John. Although I don't fully know the reasons, I doubt very much > > that it was anything to do something as specific as byte-pkt arguments. > > That wasn't implied either... > > But perhaps we _do_ need to review that decision. :^( > > Usually I'd sleep on it before saying things like this; but I do >think there's something wrong with removing two principal editors >without the principal author knowing the reasons. Do either of our >WGCs want to comment on _that_? > > >> Apparently Bob is getting ready to purge Matt Mathis. :^( :^( > > Appearances _can_ be misleading, I admit... > > > Why would I be talking offlist with Matt if it was my intention to purge > > him? > > True, that is not Bob's normal style. > > > Everyone works off-list with their co-authors. I primarily talk > > off-list to keep the signal to noise ratio high for postings on list. > > This isn't always best. > > The list has become near-dormant, IMHO, because folks couldn't follow >the reasoning behind announced changes to the text. (I have some reason >to believe even the _authors_ sometimes couldn't follow these.) > > > We (obviously) had a huge amount of off-list discussion before > > posting the lastest accecn draft. We put our rationale in the draft, > > and now we've published it for review and comment by the whole WG. > > Nothing unusual about any of that. > > I haven't yen decided whether it's worth-while commenting on accecn. >If I do, I'll mention that the complexity of Bob's "urgent pointer" >proposal is a potentially serious drawback... > > >> In fact, ECN feedback _has_ to reflect packets. All the noise about > >> what senders "could" do is just rationalizing. :^( > > > > Not so, on both counts. > > 1) In accecn (so far), we could have reflected bytes counts (as TCP > > does with seq nos & ack nos). > > Indeed, with a much longer TCP option, Bob could have proposed >counters for payload bytes. Need I remind anyone that payload bytes >is always less than bytes-on-the-wire? > > > We chose to feedback marked packets because it should be sufficient > > to be interpreted either as bytes or packets - on the same basis that > > an ECN marking at the IP layer can be interpreted as either the bytes > > in the marked packets, or the number of marked packets. This also kept > > header overhead low enough to fit within existing fields by overloading > > - an attempt to minimise the chance of being tampered with by > > middleboxes. > > Frankly, this still sounds like rationalizing to me, but YMMV. > > > 2) I deferred to Mirja & Richard for determining what senders could > > do, given their respective expertise in Linux & FreeBSD > > implementations. > > Thank you. > > >> Technically, it is possible for some future transport to use ECN > >> and count bytes instead of packets: I remain unconvinced that this > >> could ever _accurately_ count bytes-on-the-wire (which is what > >> byte-congestible _means_). > > > > What's the problem? If an ECN mark is interpreted in bytes, you just > > add up the sizes of the marked packets, rather than counting just the > > number of marked packets. > > Alas, Bob has always been a bit vague about what exactly he counts >when he counts bytes. > > Neither the sender nor the receiver can know what the overhead is >in terms of bytes-on-the-wire. In some cases they can't even agree >on the size of the packet as sent or received. > > I have usually guessed that Bob wishes to count payload bytes -- >on which the sender and receiver _can_ agree. This, of course, would >seriously under-count bytes-on-the-wire for small packets. > > If Bob instead wants to count total-bytes-in-the-sent-packet, it >would help if he defined _how_ he wants to calculate that. (Any way >he might choose, though, will under-count bytes in some cases or >over-count bytes in most cases.) > > > Or is your concern about which headers were on the packet when it > > was marked, that may have been stripped before they reach the > > transport? > > That, I suppose, is a small part of my concern... > > > If that is your only concern, then we will have made progress. This > > is something I have dismissed as an approximation error, particularly > > given congestion counts are universally normalised into proportions > > (marked vs total bytes, or marked vs total packets), and in general > > all the packets will have had the same headers stripped. > > If I were happy to dismiss approximation errors, I would have >pointed out that in practice approximating bytes by counting exactly >one byte per packet (or choose any other constant number) doesn't >work that badly in practice. > > Approximation errors aren't always small; and they often tend >to go in the same direction, which becomes significant over time... > > >> I'm afraid it's not only 6789 that's doomed. ConEx is very likely > >> to be shut down entirely. Right now we're being told to get on schedule; > >> but in essence we _can't_ stay on schedule: thus the question is whether > >> we'll get this draft to the IESG before we're shut down, not _whether_ > >> we'll be shut down. :^( > > > > Constructive comment? > > I'd be happy to hear suggestions on how to restate that as such... > > >> I would still like ConEx to produce a practical system for making > >> congestion visible within the routing cloud. I don't see any way for > >> that to happen. Thus, I simply support Matt on this question. > > > > So do I. > > Perhaps there _is_ hope -- but I'm not fully convinced. :^( > >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT From nobody Mon Aug 11 16:26:17 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 2B0EF1A011B for ; Mon, 11 Aug 2014 16:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, 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 WafsCJY-knrc for ; Mon, 11 Aug 2014 16:26:13 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2D71A04E7 for ; Mon, 11 Aug 2014 16:26:12 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 12 Aug 2014 00:26:10 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 12 Aug 2014 00:26:10 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 12 Aug 2014 00:26:09 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.49.191]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7BNQ6Gd022734; Tue, 12 Aug 2014 00:26:07 +0100 Message-ID: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Aug 2014 00:26:01 +0100 To: Suresh KRISHNAN , Mirja KUEHLEWIND , Carlos Ucendo 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/SpdCzewfeZNI6Szr5cMrEUTq0ME Cc: ConEx IETF list Subject: [conex] Review: draft-ietf-conex-destopt-06 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, 11 Aug 2014 23:26:16 -0000 Suresh, Mirja, Carlos, As promised at the authors mtg in Toronto, I have reviewed draft-ietf-conex-destopt-06. At this late stage, I prefer to suggest text, not just criticise. But pls don't take this to mean I expect you to use my suggested text. I had a lot of nits, so I thought it easiest to deal with these by annotating the draft (using MS Word, but also supplied as PDF output): I have also included all my more substantial concerns in the above annotations - highlighted in yellow. I've listed the major items here, as hooks if mailing list discussion is needed on any of them (but see the annotations for detail before discussing). My most controversial disagreement is around IPsec compatibility, which we ought to spin into a separate thread if you want to discuss/argue. Most of the other additions are because conex-abstract-mech says a concrete protocol spec has to address specific aspects, which weren't addressed. ==Intro== * Added scoping in Intro (solely wire protocol; specific transport protocol specs will determine when specifically to set each marking, e.g. conex-tcp-modifications) * Standards Track -> Experimental * Added subsection of intro on experiment goals: criteria for success and duration ==Requirements== * Referred to abstract-mech for requirements, explained that it would be hard to satisfy them all, and explained which one wasn't satisfied (visibility in outer), referring to section on fast-path performance. ==CDO== * For any text about ignoring invalid fields, explicitly said that intermediate nodes MUST NOT normalise. Also, specified to treat packets with invalid fields like a non-ConEx-capable packet. * Specified precisely which IP header is included in the byte count. * Suggested deleting example of Not-ConEx-capable packets (see separate thread to conex-tcp-modifications authors about TCP pure ACKs). ==Fast-path== * CDO as first destination option: changed from MUST to SHOULD (with an example of when not to). ==Config & Management== * Added section, mainly to say there is no config & mgmt (required by abstract-mech). ==IPsec compatibility== * Suggested ConEx counts the AH header, and the outer tunnel mode header, with reasoning. * Suggested the section is restructured because I believe the visibility problem is not related to tunnel mode, but only to ESP in tunnel mode. * Added a para about the possibility of implementing a ConEx proxy (without breaking e2e authentication). ==Tunnelling== * Section added, to generalise from just IPsec to any IP-in-IP tunnelling (particularly relevant to mobile scenarios). * Suggested optional copying of CDO to outer, but also a simpler 'Do not copy CDO' alternative. ==Security Considerations== * Added lots, all pointers to where security issues are discussed in other places (which is what security directorate reviewers need). ==IANA== * I think the act bits need to be 00 not 10 to avoid ConEx packets being dropped by non-ConEx nodes (including by non-ConEx receivers)? But I'm willing to be corrected. Regards Bob ________________________________________________________________ Bob Briscoe, BT From nobody Tue Aug 12 02:04: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 97EF81A07AC for ; Tue, 12 Aug 2014 02:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 nPbRGas8UnSP for ; Tue, 12 Aug 2014 02:04:03 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149BC1A07A8 for ; Tue, 12 Aug 2014 02:04:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,847,1400050800"; d="scan'208";a="181449481" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 12 Aug 2014 02:04:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht04-prd.hq.netapp.com (10.106.77.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 12 Aug 2014 02:03:32 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 12 Aug 2014 02:03:31 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::c1bc:1fd5:922:886d%21]) with mapi id 15.00.0913.011; Tue, 12 Aug 2014 02:03:20 -0700 From: "Scheffenegger, Richard" To: Bob Briscoe Thread-Topic: ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05) Thread-Index: AQHPtWHz2i+Ekg14OEq23ra1x9j48JvLXEywgACRsGiAAL4qQA== Date: Tue, 12 Aug 2014 09:03:19 +0000 Message-ID: <0730db69e74f4dcd9da8924f96b65eb3@hioexcmbx05-prd.hq.netapp.com> References: <201408111244.s7BCiA7m021070@bagheera.jungle.bt.co.uk> <61f7d201e0484835825c74e3fcca2f8f@hioexcmbx05-prd.hq.netapp.com> <201408112137.s7BLbDoc022547@bagheera.jungle.bt.co.uk> In-Reply-To: <201408112137.s7BLbDoc022547@bagheera.jungle.bt.co.uk> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/yRZKTGN712_ZG4iaxYN4W6CjzsI Cc: Mirja KUEHLEWIND , "conex@ietf.org" Subject: Re: [conex] ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05) 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, 12 Aug 2014 09:04:07 -0000 Hi Bob, in the context of TCP, segment A is likely to be a pure ACK too; which woul= d not be marked ECT per 3168, or at least the receiver would not reflect an= y mark (or loss) of such a pure ACK back (B). But you are correct in the example, when A is a data segment, B is a data s= egment, and C is a pure ACK, the sender should not withhold or delay Conex = information. And I fully agree with your observation that this paragraph ha= s it upside down. With a modification in the TCP semantics (AccECN), that example would exten= d to cases where either A or B (or both) are pure ACKs as well, that get EC= N marked, so C would have the appropriate E bit set; Only ACK losses would = not cause a Conex L bit, as pure ACK losses are not detected. Best regards, Richard Scheffenegger > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: Montag, 11. August 2014 23:37 > To: Scheffenegger, Richard > Cc: Mirja KUEHLEWIND > Subject: RE: ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05) >=20 > Richard, >=20 > At 14:02 11/08/2014, Scheffenegger, Richard wrote: > >Hi Bob, > > > >I believe you are making the argument for really symetric signaling; > >like what we had discussed for AccECN and pure ACKs for the ECN header. > > > >And I agree with you, for a symmetric signal it doesn't make any sense > >to exclude some fraction of segments from that stream; the X bit by > >itself only signifies that this stream could have some conex markings > >also... >=20 > No, no, no. I agree with your conclusion, but your reason is misplaced. >=20 >=20 > >I guess the better approach might be to state something like: > > > > > > Current TCP ECN mechanisms do not provide congestion feedback > > information > > about control packets such as pure ACKs which are not carrying an= y > > payload. > > > > However, even though no conex information may be available, > > future mechanisms > > could provide appropriate feedback. Therefore, these packets > > MUST carry a > > Conex Destination option with the X bit set, but both L and E > > bits SHOULD be > > unset, unless the sender has means to determine that control > > packets were > > lost or marked with CE. >=20 > No. No. No. Nothing to do with any of this TCP feedback stuff. > Please reboot brain into ConEx mode. >=20 > ConEx info is about the packet 1 RTT earlier (A), that triggered an ACK i= n > the opposite direction (B), which in turn triggered this pure ACK we're > talking about (C). >=20 > ConEx info on C is not about the possible loss or possible congestion > marking in the IP layer of C itself. ConEx info on C is not even anything > to do with the congestion feedback in the TCP layer of C. >=20 > |` . data | > |` . ` . | > | ` . ` x(loss) | > | ` . | > | ` . | > | A ` >| > | . '| > | . ' | > | . ' | > | B . ' data + SACK| > |< ' | > |` . | > | ` . | > | ` . | > | ` . C | > | ` >| >=20 >=20 > The question of what ConEx marking there is on packet C doesn't depend on > whether C is a pure ACK (or not). From the ConEx point of view, C is just > an IP packet. ConEx doesn't care what's in packet C at the TCP layer. It'= s > just an IP packet to put a CoNEx marking on. >=20 > There is absolutely no reason to say a pure ACK should not be marked > ConEx-capable. >=20 > Indeed, once a host transport stack is ConEx-capable, it can mark all > packets that it sends as ConEx-capable, irrespective of whether the other > end supports ConEx (there's no such thing as 'supporting ConEx' > for a receiver). >=20 > Regards >=20 >=20 > Bob >=20 >=20 >=20 >=20 > >Richard Scheffenegger > > > > > > > > > > > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > > Sent: Montag, 11. August 2014 14:44 > > > To: Mirja KUEHLEWIND; Scheffenegger, Richard > > > Subject: ConEx on Pure ACKs (draft-ietf-conex-tcp-modifications-05) > > > > > > Mirja, Richard, > > > > > > I don't see why TCP pure ACKs need to have ConEx-capable turned off > (X=3D0). > > > > > > draft-ietf-conex-tcp-modifications-05 says: > > > " > > > No congestion feedback information are available > > > about control packets such as pure ACKs which are not carrying an= y > > > payload. Thus these packets should not be taken into account whe= n > > > determining ConEx information. These packet MUST carry a ConEx > > > Destination Option with the X bit unset. > > > " > > > > > > However, ConEx on one packet isn't about the feedback in /that/ > packet. > > > > > > A stream of pure ACKs could be useful to send ConEx markings, > > > particularly if a host that is primarily a data receiver doesn't > > > often send data packets, but needs to send some timely ConEx > > > markings to make up a deficit in marking. Even tho a pure ACK > > > doesn't carry many bytes (80B incl IPv6 header), it's better than > nothing. > > > > > > A network operator is entitled to police non-ConEx-capable packets > > > more stringently than ConEx capable, so a TCP sender doesn't want to > > > risk losing pure ACKs more than other packets. > > > > > > > > > Bob > > > > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT >=20 > ________________________________________________________________ > Bob Briscoe, BT From nobody Tue Aug 12 10:29: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 D4A731A040A; Tue, 12 Aug 2014 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 JPnXJdDj3gYx; Tue, 12 Aug 2014 10:29:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E071A034B; Tue, 12 Aug 2014 10:29:39 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7CHTUsB002205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 12 Aug 2014 12:29:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53EA4EFA.9040601@nostrum.com> Date: Tue, 12 Aug 2014 12:29:30 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> In-Reply-To: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> Content-Type: multipart/alternative; boundary="------------060704040000080506080501" Archived-At: http://mailarchive.ietf.org/arch/msg/conex/M0g-lpyjXL12faUWz2S8SlhMV0c Cc: "ietf@ietf.org" , General Area Review Team , conex@ietf.org, 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: Tue, 12 Aug 2014 17:29:47 -0000 This is a multi-part message in MIME format. --------------060704040000080506080501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 > 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 need > to go to the trouble of updating 6789. So, instead, we have qualified > the applicability of 6789 in this document. > > ======================================================================= > 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 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. > 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]. > ======================================================================= > > 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 >> > >. >> 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  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, BT > --------------060704040000080506080501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 need to go to the trouble of updating 6789. So, instead, we have qualified the applicability of 6789 in this document.

=======================================================================
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 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.
   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].
=======================================================================

Regards


Bob Briscoe & Matt Mathis


On Wed, Aug 6, 2014 at 1:28 AM, Robert Sparks <rjsparks@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>.
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  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,                                                  BT


--------------060704040000080506080501-- From nobody Tue Aug 12 11:44:00 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 5522E1A0573 for ; Tue, 12 Aug 2014 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 nXd-Vf4O11Ri for ; Tue, 12 Aug 2014 11:43:56 -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 D44E21A0012 for ; Tue, 12 Aug 2014 11:43:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BAF0AD9310; Tue, 12 Aug 2014 20:43:53 +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 S004EfN0LP5r; Tue, 12 Aug 2014 20:43:53 +0200 (MEST) 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 88DA5D930B; Tue, 12 Aug 2014 20:43:53 +0200 (MEST) Message-ID: <53EA6068.6090100@tik.ee.ethz.ch> Date: Tue, 12 Aug 2014 20:43:52 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/rSqqz767GxA-XmlKP2Wona7y9j0 Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 12 Aug 2014 18:43:59 -0000 Hi Bob, thanks for your review. Please see comments inline. (Please also note my new email address...) > ---------- Forwarded Message ---------- > > Subject: Review: draft-ietf-conex-destopt-06 > Date: Tuesday 12 August 2014, 01:26:01 > From: Bob Briscoe > To: Suresh KRISHNAN , Mirja KUEHLEWIND > , Carlos Ucendo > CC: ConEx IETF list > > Suresh, Mirja, Carlos, > > As promised at the authors mtg in Toronto, I have reviewed > draft-ietf-conex-destopt-06. > > At this late stage, I prefer to suggest text, not just criticise. But > pls don't take this to mean I expect you to use my suggested text. > > I had a lot of nits, so I thought it easiest to deal with these by > annotating the draft (using MS Word, but also supplied as PDF output): > > > > I have also included all my more substantial concerns in the above > annotations - highlighted in yellow. > > I've listed the major items here, as hooks if mailing list discussion > is needed on any of them (but see the annotations for detail before > discussing). > > My most controversial disagreement is around IPsec compatibility, > which we ought to spin into a separate thread if you want to discuss/argue. > > Most of the other additions are because conex-abstract-mech says a > concrete protocol spec has to address specific aspects, which weren't > addressed. > > ==Intro== > * Added scoping in Intro (solely wire protocol; specific transport > protocol specs will determine when specifically to set each marking, > e.g. conex-tcp-modifications) k. I added something to the previous paragraph because this was already intended to say that this document is mainly for people that implement a network node and want to do something with ConEx. > > * Standards Track -> Experimental Yes, thanks. > * Added subsection of intro on experiment goals: criteria for success > and duration I believe most of the text actually should go in the tcp mods draft. I not sure if there is a common sense in the mean time to have such a section in very exp document. But if not I would rather not have it in this document because I'm not sure how to define if an experiment was successful. If fact the CDO is the only approach at could fulfill our requirements, so there is no other option. And if the coding itself with the four bits is useful or not, is not really a question of this document, but amybe more of the whole mechanism (incl. auditing and policing) or maybe the tcp mods document...? > > ==Requirements== > > * Referred to abstract-mech for requirements, explained that it would > be hard to satisfy them all, and explained which one wasn't satisfied > (visibility in outer), referring to section on fast-path performance. Took over some of your text at the beginning of this section (and also reused some text we already used to have there). Do you really think that the two requirements you've added are needed? Because both basically say that the ConEx coding should encode the Conex signal, which is, from my point of view, the whole purpose of this document. I do have the feeling that the other requirements listed here are on a slightly different level because they are more related to deployment issues. And regarding tunneling: you are right that we need to give more advise on tunneling. Shouldn't we just say that one MUST copy the inner ConEx Option to the outer header (to solve the visibility problem)? > > ==CDO== The current version says 'immediate nodes SHOULD only read the CDO field' which you changed to 'MUST forward unaltered'. This 'SHOULD' was actually a SHOULD because you (!) came up with the idea that a policer should be able to remove ConEx markings instead of dropping immediately. I don't think and never thought that this is a good idea because it changes the ConEx information for other nodes later on the path. If you think that is definitely not needed anymore, I'm happy to have a MUST there. > > * For any text about ignoring invalid fields, explicitly said that > intermediate nodes MUST NOT normalise. Also, specified to treat > packets with invalid fields like a non-ConEx-capable packet. ACK, will add your text here. > > * Specified precisely which IP header is included in the byte count. So you suggest to not include any options? Why? I'd say you either include all bits because all of them contribute to congestion, or none of the IP header bits because that's just the overhead you can't avoid if you what to send anything. Also of course you can generate a larger percentage of overhead if you send smaller packets. > > * Suggested deleting example of Not-ConEx-capable packets (see > separate thread to conex-tcp-modifications authors about TCP pure ACKs). I can remove the example but not sure why you are suggesting this. If you actually imply that the X bit should never be zero that we have to discuss if the X bit is needed at all. > > ==Fast-path== > > * CDO as first destination option: changed from MUST to SHOULD (with > an example of when not to). I believe this really needs to be a MUST. I know that might restrict the use of ConEx with potential other options that might have the same requirement (for different reasons). But if you don't put a MUST here, you cannot implemented the suggested way in the fast path. > > ==Config & Management== > > * Added section, mainly to say there is no config & mgmt (required by > abstract-mech). I don't thing that the statement about being able to switch ConEx on and off belongs in this document (but in tcp mods). I can add one sentence on warnings or error messages if really needed, but I don't think that needs an own section. > > ==IPsec compatibility== > > * Suggested ConEx counts the AH header, and the outer tunnel mode > header, with reasoning. Yes, need to be more precise. Will add. > > * Suggested the section is restructured because I believe the > visibility problem is not related to tunnel mode, but only to ESP in > tunnel mode. I agree that tunneling was not addressed well. > > * Added a para about the possibility of implementing a ConEx proxy > (without breaking e2e authentication). ACK will add. > > ==Tunnelling== > > * Section added, to generalise from just IPsec to any IP-in-IP > tunnelling (particularly relevant to mobile scenarios). If we have a separate section on tunneling. Shouldn't we have tunning first and then IPSec...? > > * Suggested optional copying of CDO to outer, but also a simpler 'Do > not copy CDO' alternative. I don't really get you SHOULD NOT but MAY here...? > > ==Security Considerations== > > * Added lots, all pointers to where security issues are discussed in > other places (which is what security directorate reviewers need). Okay I can add that if you think it's necessary (I would say it's just redundant, but you be might right that it just helps the sec dir). > > ==IANA== > > * I think the act bits need to be 00 not 10 to avoid ConEx packets > being dropped by non-ConEx nodes (including by non-ConEx receivers)? > But I'm willing to be corrected. I agree; Will ask Suresh why he has put a 10 though. Thanks, Mirja > > > Regards > > > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT > > > ------------------------------------------------------- > -- ------------------------------------------ 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 Wed Aug 13 02:19:29 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 6945F1A8547 for ; Wed, 13 Aug 2014 02:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 CLyQx23632dY for ; Wed, 13 Aug 2014 02:19:23 -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 48C091A8035 for ; Wed, 13 Aug 2014 02:19:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9018FD930E; Wed, 13 Aug 2014 11:19:21 +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 f-V0jk9JSDFD; Wed, 13 Aug 2014 11:19:21 +0200 (MEST) 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 4A16CD930D; Wed, 13 Aug 2014 11:19:21 +0200 (MEST) Message-ID: <53EB2D99.1070101@tik.ee.ethz.ch> Date: Wed, 13 Aug 2014 11:19:21 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bob Briscoe , Suresh KRISHNAN , Carlos Ucendo , Carlos Ucendo References: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk> In-Reply-To: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/ahIBzoPb8upA8nRX6EhyyWPNneg Cc: ConEx IETF list Subject: Re: [conex] Review: draft-ietf-conex-destopt-06 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, 13 Aug 2014 09:19:26 -0000 Hi Bob, one more question: you added one paragraph on multicast. I would propose to even say "A ConEx sender MUST NOT send a packet with the CDO to a multicast address." instead of "A ConEx sender MUST NOT send a packet with X = 1 (ConEx-capable) to a multicast address, and it SHOULD NOT even include the CDO in such a packet." as you proposed. Or is there a reason to have a SHOULD? Original I wrote the document from the point of view of someone how wants to implement a ConEx-aware network node. So I believe a never said anyway how an end node should act. So this sentence introduces a MUST for end nodes. But i guess it is still needed in this document, right? Mirja On 12.08.2014 01:26, Bob Briscoe wrote: > Suresh, Mirja, Carlos, > > As promised at the authors mtg in Toronto, I have reviewed > draft-ietf-conex-destopt-06. > > At this late stage, I prefer to suggest text, not just criticise. But > pls don't take this to mean I expect you to use my suggested text. > > I had a lot of nits, so I thought it easiest to deal with these by > annotating the draft (using MS Word, but also supplied as PDF output): > > > > > > I have also included all my more substantial concerns in the above > annotations - highlighted in yellow. > > I've listed the major items here, as hooks if mailing list discussion is > needed on any of them (but see the annotations for detail before > discussing). > > My most controversial disagreement is around IPsec compatibility, which > we ought to spin into a separate thread if you want to discuss/argue. > > Most of the other additions are because conex-abstract-mech says a > concrete protocol spec has to address specific aspects, which weren't > addressed. > > ==Intro== > * Added scoping in Intro (solely wire protocol; specific transport > protocol specs will determine when specifically to set each marking, > e.g. conex-tcp-modifications) > > * Standards Track -> Experimental > * Added subsection of intro on experiment goals: criteria for success > and duration > > ==Requirements== > > * Referred to abstract-mech for requirements, explained that it would be > hard to satisfy them all, and explained which one wasn't satisfied > (visibility in outer), referring to section on fast-path performance. > > ==CDO== > > * For any text about ignoring invalid fields, explicitly said that > intermediate nodes MUST NOT normalise. Also, specified to treat packets > with invalid fields like a non-ConEx-capable packet. > > * Specified precisely which IP header is included in the byte count. > > * Suggested deleting example of Not-ConEx-capable packets (see separate > thread to conex-tcp-modifications authors about TCP pure ACKs). > > ==Fast-path== > > * CDO as first destination option: changed from MUST to SHOULD (with an > example of when not to). > > ==Config & Management== > > * Added section, mainly to say there is no config & mgmt (required by > abstract-mech). > > ==IPsec compatibility== > > * Suggested ConEx counts the AH header, and the outer tunnel mode > header, with reasoning. > > * Suggested the section is restructured because I believe the visibility > problem is not related to tunnel mode, but only to ESP in tunnel mode. > > * Added a para about the possibility of implementing a ConEx proxy > (without breaking e2e authentication). > > ==Tunnelling== > > * Section added, to generalise from just IPsec to any IP-in-IP > tunnelling (particularly relevant to mobile scenarios). > > * Suggested optional copying of CDO to outer, but also a simpler 'Do not > copy CDO' alternative. > > ==Security Considerations== > > * Added lots, all pointers to where security issues are discussed in > other places (which is what security directorate reviewers need). > > ==IANA== > > * I think the act bits need to be 00 not 10 to avoid ConEx packets being > dropped by non-ConEx nodes (including by non-ConEx receivers)? But I'm > willing to be corrected. > > > Regards > > > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > > -- ------------------------------------------ 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 Wed Aug 13 12: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 48B451A0467 for ; Wed, 13 Aug 2014 12:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 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.668, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=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 dWpnxQsr62oZ for ; Wed, 13 Aug 2014 12:06:35 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22641A0456 for ; Wed, 13 Aug 2014 12:06:34 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 20:06:31 +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, 13 Aug 2014 20:06:32 +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, 13 Aug 2014 20:06:32 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7DJ6V2s029587; Wed, 13 Aug 2014 20:06:31 +0100 Message-ID: <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2014 20:06:30 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <53EA6068.6090100@tik.ee.ethz.ch> References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/hT6r_BcbtU8NsaJr-P9NDRLzFmI Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 13 Aug 2014 19:06:43 -0000 Mirja, At 19:43 12/08/2014, Mirja K=FChlewind wrote: >Hi Bob, > >thanks for your review. Please see comments inline. > >(Please also note my new email address...) > > > >>---------- Forwarded Message ---------- >> >>Subject: Review: draft-ietf-conex-destopt-06 >>Date: Tuesday 12 August 2014, 01:26:01 >>From: Bob Briscoe >>To: Suresh KRISHNAN , Mirja KUEHLEWIND >>, Carlos Ucendo >>CC: ConEx IETF list >> >>Suresh, Mirja, Carlos, >> >>As promised at the authors mtg in Toronto, I have reviewed >>draft-ietf-conex-destopt-06. >> >>At this late stage, I prefer to suggest text, not just criticise. But >>pls don't take this to mean I expect you to use my suggested text. >> >>I had a lot of nits, so I thought it easiest to deal with these by >>annotating the draft (using MS Word, but also supplied as PDF output): >> >> >> >>I have also included all my more substantial concerns in the above >>annotations - highlighted in yellow. >> >>I've listed the major items here, as hooks if mailing list discussion >>is needed on any of them (but see the annotations for detail before >>discussing). >> >>My most controversial disagreement is around IPsec compatibility, >>which we ought to spin into a separate thread if you want to= discuss/argue. >> >>Most of the other additions are because conex-abstract-mech says a >>concrete protocol spec has to address specific aspects, which weren't >>addressed. >> >>=3D=3DIntro=3D=3D >>* Added scoping in Intro (solely wire protocol; specific transport >>protocol specs will determine when specifically to set each marking, >>e.g. conex-tcp-modifications) > >k. I added something to the previous paragraph=20 >because this was already intended to say that=20 >this document is mainly for people that=20 >implement a network node and want to do something with ConEx. Surely this doc is just as important for the=20 sender, esp as a generic definition of the ConEx=20 protocol for all transport protocols, not just TCP. >>* Standards Track -> Experimental >Yes, thanks. > >>* Added subsection of intro on experiment goals: criteria for success >>and duration > >I believe most of the text actually should go in=20 >the tcp mods draft. I not sure if there is a=20 >common sense in the mean time to have such a=20 >section in very exp document. But if not I would=20 >rather not have it in this document because I'm=20 >not sure how to define if an experiment was=20 >successful. If fact the CDO is the only approach=20 >at could fulfill our requirements, so there is=20 >no other option. And if the coding itself with=20 >the four bits is useful or not, is not really a=20 >question of this document, but amybe more of the=20 >whole mechanism (incl. auditing and policing) or=20 >maybe the tcp mods document...? The solution to this would be to refer to one doc=20 that has the expt goals. However, I believe each=20 doc can be seen as a separate piece of a bigger expt. * The expt that this doc describes is a choice of=20 encoding (see below - there are other choices). * The main expt that the TCP doc describes is how to set credit. >>=3D=3DRequirements=3D=3D >> >>* Referred to abstract-mech for requirements, explained that it would >>be hard to satisfy them all, and explained which one wasn't satisfied >>(visibility in outer), referring to section on fast-path performance. > >Took over some of your text at the beginning of=20 >this section (and also reused some text we already used to have there). > >Do you really think that the two requirements=20 >you've added are needed? Because both basically=20 >say that the ConEx coding should encode the=20 >Conex signal, which is, from my point of view,=20 >the whole purpose of this document. Perhaps you're too close to ConEx. If these reqs=20 hadn't been defined in abstract-mech, you=20 wouldn't know what "the ConEx signal" was. These=20 reqs say what the component parts of the ConEx=20 signal are. It could say you need separate=20 signals for ECN-credit and loss-credit. It could=20 say ConEx nodes must successfully negotiate ECN=20 (then re-ECN would be a solution). The alternative is to refer to abstract-mech for=20 all the requirements and not list them here, or=20 list the reqs in abstract-mech that are relevant to the network layer= encoding. >I do have the feeling that the other=20 >requirements listed here are on a slightly=20 >different level because they are more related to deployment issues. You could say that (but you don't). That's why it=20 seemed odd that you listed some requirements, but not the basic ones. >And regarding tunneling: you are right that we=20 >need to give more advise on tunneling. Shouldn't=20 >we just say that one MUST copy the inner ConEx=20 >Option to the outer header (to solve the visibility problem)? You can't say MUST, because IPv6 dest opts are=20 meant to be e2e only, so no IPv6 tunnel currently=20 even understands what a dest opt is, let alone=20 copies any dest opt to the outer. A MUST would=20 ring huge alarm bells in the vendor community. I added it as a MAY, purely because it might be=20 considered a performance optimisation. I'm still=20 worried about the size of the alarm bells that=20 will ring. It could prevent this draft=20 progressing thru the IESG. Suresh will know best=20 how this might be received in the IESG. >>=3D=3DCDO=3D=3D > >The current version says 'immediate nodes SHOULD=20 >only read the CDO field' which you changed to=20 >'MUST forward unaltered'. This 'SHOULD' was=20 >actually a SHOULD because you (!) came up with=20 >the idea that a policer should be able to remove=20 >ConEx markings instead of dropping immediately. >I don't think and never thought that this is a=20 >good idea because it changes the ConEx=20 >information for other nodes later on the path.=20 >If you think that is definitely not needed=20 >anymore, I'm happy to have a MUST there. OK, you got me. Let's make this a MUST. I forgot about what my other personality thought=20 when I visited you back in 2010;) My currently dominant personality isn't convinced=20 by those rather tentative ideas.{See Note 1} >>* For any text about ignoring invalid fields, explicitly said that >>intermediate nodes MUST NOT normalise. Also, specified to treat >>packets with invalid fields like a non-ConEx-capable packet. > >ACK, will add your text here. > >> >>* Specified precisely which IP header is included in the byte count. >So you suggest to not include any options? I didn't say that, did I? If the wording I used is ambiguous, pls fix it. >Why? I'd say you either include all bits because=20 >all of them contribute to congestion, or none of=20 >the IP header bits because that's just the=20 >overhead you can't avoid if you what to send=20 >anything. Also of course you can generate a=20 >larger percentage of overhead if you send smaller packets. That's why I think it is reasonable to include=20 the IP header (and its options) that immediately=20 encapsulates the ConEx dest opt. >>* Suggested deleting example of Not-ConEx-capable packets (see >>separate thread to conex-tcp-modifications authors about TCP pure ACKs). >I can remove the example but not sure why you=20 >are suggesting this. If you actually imply that=20 >the X bit should never be zero that we have to=20 >discuss if the X bit is needed at all. I have never thought the X flag was needed.=20 There's probably some email on the list somewhere=20 in the past from me that says that. As I put in one of the comment bubbles: "The only need I can see for the X-flag is if the Reserved field gets used in future for something in addition to ConEx. Then there would be a need to identify packets that are not ConEx-capable but still carry the CDO option (for the new reason)." Can anyone think of a use for the X flag? >>=3D=3DFast-path=3D=3D >> >>* CDO as first destination option: changed from MUST to SHOULD (with >>an example of when not to). >I believe this really needs to be a MUST. I know=20 >that might restrict the use of ConEx with=20 >potential other options that might have the same=20 >requirement (for different reasons). But if you=20 >don't put a MUST here, you cannot implemented=20 >the suggested way in the fast path. A SHOULD still means it will be the first option=20 in all current implementations. However, I=20 suggest a SHOULD, precisely because performance=20 reasons are not absolute, so they don't require a=20 MUST. If another dest opt cannot work at all=20 unless it is first, that would be a valid reason=20 for CDO coming second, because it still works, it's /just/ slower. The IESG will (rightly) be very wary of any draft=20 that says an option MUST be the first option. I suggested the following text after this: "(This is not stated as a 'MUST', because some future destination option might need to be placed first for functional rather than just performance reasons.)" >>=3D=3DConfig & Management=3D=3D >> >>* Added section, mainly to say there is no config & mgmt (required by >>abstract-mech). >I don't thing that the statement about being=20 >able to switch ConEx on and off belongs in this document (but in tcp mods). Good point. >I can add one sentence on warnings or error=20 >messages if really needed, but I don't think that needs an own section. Pls do. I was just making sure all the reqs in abstract-mech were satisfied. >>=3D=3DIPsec compatibility=3D=3D >> >>* Suggested ConEx counts the AH header, and the outer tunnel mode >>header, with reasoning. >Yes, need to be more precise. Will add. This one wasn't just clarity. I've actually=20 contradicted what was said, so pls make sure=20 there wasn't a good reason for why it was like it was. I was most concerned about suggesting this=20 change, because it was the only one that caused a technical difference. >>* Suggested the section is restructured because I believe the >>visibility problem is not related to tunnel mode, but only to ESP in >>tunnel mode. >I agree that tunneling was not addressed well. > >> >>* Added a para about the possibility of implementing a ConEx proxy >>(without breaking e2e authentication). >ACK will add. > >> >>=3D=3DTunnelling=3D=3D >> >>* Section added, to generalise from just IPsec to any IP-in-IP >>tunnelling (particularly relevant to mobile scenarios). >If we have a separate section on tunneling.=20 >Shouldn't we have tunning first and then IPSec...? Could do, I guess. >>* Suggested optional copying of CDO to outer, but also a simpler 'Do >>not copy CDO' alternative. >I don't really get you SHOULD NOT but MAY here...? See earlier. Tunnels don't normally understand=20 dest opts, which is why I said SHOULD NOT. But=20 the MAY is a performance optimisation. Am I helping? >>=3D=3DSecurity Considerations=3D=3D >> >>* Added lots, all pointers to where security issues are discussed in >>other places (which is what security directorate reviewers need). >Okay I can add that if you think it's necessary=20 >(I would say it's just redundant, but you be=20 >might right that it just helps the sec dir). It's not always obvious which aspects relate to=20 security. Especially when the security is=20 structural rather than crypto. So I think these=20 sentences are useful to sec dir. >>=3D=3DIANA=3D=3D >> >>* I think the act bits need to be 00 not 10 to avoid ConEx packets >>being dropped by non-ConEx nodes (including by non-ConEx receivers)? >>But I'm willing to be corrected. >I agree; Will ask Suresh why he has put a 10 though. Yes, he's the right guy to check with. Bob >Thanks, >Mirja > >> >> >>Regards >> >> >> >> >>Bob {Note 1} For anyone watching on the list, the tentative=20 idea that Mirja has reminded me of is documented=20 in 11.3.1 of my PhD thesis entitled "Covert Markings as a Policer Signal". The potential problem: A ConEx policer punishes=20 punishment. If a congestion policer starts=20 dropping packets because the user has contributed=20 excessively to congestion, in subsequent rounds=20 the user has to re-echo 'L' markings for the=20 policer drops as well. This can drive the policer=20 further into 'debit'. This might make it=20 difficult for the user to get out of trouble once=20 she's started getting into trouble. The basic idea was that when a congestion policer=20 drops packets (because the user is causing more=20 congestion than her allowance), it will also=20 remove ConEx markings. Then (if there is some way=20 for the receiver to feed this back), the sender=20 knows not to send more ConEx marks because these=20 aren't congestion drops, they are policer drops. We didn't that double punishment made it hard to=20 get out of trouble in any policer experiments so=20 far, so let's not allow for a possible solution=20 to a problem that we probably don't even have.=20 The current crop of ConEx drafts are experimental=20 anyway. If this problem does surface, then we can reconsider. ________________________________________________________________ Bob Briscoe, BT=20 From nobody Wed Aug 13 12:13:18 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 20DFB1A048D for ; Wed, 13 Aug 2014 12:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 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.668, 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 Khjvo6sRz8II for ; Wed, 13 Aug 2014 12:13:12 -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 0DF131A0489 for ; Wed, 13 Aug 2014 12:13:11 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 13 Aug 2014 20:13:10 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 20:13:09 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Wed, 13 Aug 2014 20:13:09 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7DJD87W029606; Wed, 13 Aug 2014 20:13:08 +0100 Message-ID: <201408131913.s7DJD87W029606@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Aug 2014 20:13:07 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <53EB2D99.1070101@tik.ee.ethz.ch> References: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk> <53EB2D99.1070101@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/IzuqhAagYX6DZVwwKCNy1XANo6Y Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Review: draft-ietf-conex-destopt-06 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, 13 Aug 2014 19:13:16 -0000 Mirja, At 10:19 13/08/2014, Mirja K=FChlewind wrote: >Hi Bob, > >one more question: you added one paragraph on=20 >multicast. I would propose to even say > >"A ConEx sender MUST NOT send a packet with the CDO to a multicast= address." > >instead of > >"A ConEx sender MUST NOT send a packet with X =3D 1 (ConEx-capable) >to a multicast address, and it SHOULD NOT even=20 >include the CDO in such a packet." > >as you proposed. Or is there a reason to have a SHOULD? The only reason I had was that there might in=20 future be other things in a CDO (in the field=20 that is currently Reserved) that are applicabile=20 to multicast. If any security device vendors read=20 every IETF spec, I thought it would be best not=20 to cause them to programme their kit to drop=20 multicast packets if they carry CDO, which would constrain evolvability. I guess, if it is a SHOULD, it ought give an=20 example of where the SHOULD does not apply, and=20 my example is a bit subtle to have to explain. Up to you. Bob >Original I wrote the document from the point of=20 >view of someone how wants to implement a=20 >ConEx-aware network node. So I believe a never=20 >said anyway how an end node should act. So this=20 >sentence introduces a MUST for end nodes. But i=20 >guess it is still needed in this document, right? > >Mirja > > >On 12.08.2014 01:26, Bob Briscoe wrote: >>Suresh, Mirja, Carlos, >> >>As promised at the authors mtg in Toronto, I have reviewed >>draft-ietf-conex-destopt-06. >> >>At this late stage, I prefer to suggest text, not just criticise. But >>pls don't take this to mean I expect you to use my suggested text. >> >>I had a lot of nits, so I thought it easiest to deal with these by >>annotating the draft (using MS Word, but also supplied as PDF output): >> >> >> >> >> >>I have also included all my more substantial concerns in the above >>annotations - highlighted in yellow. >> >>I've listed the major items here, as hooks if mailing list discussion is >>needed on any of them (but see the annotations for detail before >>discussing). >> >>My most controversial disagreement is around IPsec compatibility, which >>we ought to spin into a separate thread if you want to discuss/argue. >> >>Most of the other additions are because conex-abstract-mech says a >>concrete protocol spec has to address specific aspects, which weren't >>addressed. >> >>=3D=3DIntro=3D=3D >>* Added scoping in Intro (solely wire protocol; specific transport >>protocol specs will determine when specifically to set each marking, >>e.g. conex-tcp-modifications) >> >>* Standards Track -> Experimental >>* Added subsection of intro on experiment goals: criteria for success >>and duration >> >>=3D=3DRequirements=3D=3D >> >>* Referred to abstract-mech for requirements, explained that it would be >>hard to satisfy them all, and explained which one wasn't satisfied >>(visibility in outer), referring to section on fast-path performance. >> >>=3D=3DCDO=3D=3D >> >>* For any text about ignoring invalid fields, explicitly said that >>intermediate nodes MUST NOT normalise. Also, specified to treat packets >>with invalid fields like a non-ConEx-capable packet. >> >>* Specified precisely which IP header is included in the byte count. >> >>* Suggested deleting example of Not-ConEx-capable packets (see separate >>thread to conex-tcp-modifications authors about TCP pure ACKs). >> >>=3D=3DFast-path=3D=3D >> >>* CDO as first destination option: changed from MUST to SHOULD (with an >>example of when not to). >> >>=3D=3DConfig & Management=3D=3D >> >>* Added section, mainly to say there is no config & mgmt (required by >>abstract-mech). >> >>=3D=3DIPsec compatibility=3D=3D >> >>* Suggested ConEx counts the AH header, and the outer tunnel mode >>header, with reasoning. >> >>* Suggested the section is restructured because I believe the visibility >>problem is not related to tunnel mode, but only to ESP in tunnel mode. >> >>* Added a para about the possibility of implementing a ConEx proxy >>(without breaking e2e authentication). >> >>=3D=3DTunnelling=3D=3D >> >>* Section added, to generalise from just IPsec to any IP-in-IP >>tunnelling (particularly relevant to mobile scenarios). >> >>* Suggested optional copying of CDO to outer, but also a simpler 'Do not >>copy CDO' alternative. >> >>=3D=3DSecurity Considerations=3D=3D >> >>* Added lots, all pointers to where security issues are discussed in >>other places (which is what security directorate reviewers need). >> >>=3D=3DIANA=3D=3D >> >>* I think the act bits need to be 00 not 10 to avoid ConEx packets being >>dropped by non-ConEx nodes (including by non-ConEx receivers)? But I'm >>willing to be corrected. >> >> >>Regards >> >> >> >> >>Bob >> >> >> >>________________________________________________________________ >>Bob Briscoe, BT >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex >> > >-- >------------------------------------------ >Dipl.-Ing. Mirja K=FChlewind >Communication Systems Group >Institute TIK, ETH Z=FCrich >Gloriastrasse 35, 8092 Z=FCrich, Switzerland > >Room ETZ G93 >phone: +41 44 63 26932 >email: mirja.kuehlewind@tik.ee.ethz.ch >------------------------------------------ ________________________________________________________________ Bob Briscoe, BT=20 From nobody Wed Aug 13 12:41:00 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 E2E561A05F5 for ; Wed, 13 Aug 2014 12:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 F9DLM4Mf9o-q for ; Wed, 13 Aug 2014 12:40:54 -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 CFCAA1A0538 for ; Wed, 13 Aug 2014 12:40:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7EB7ED930D; Wed, 13 Aug 2014 21:40:51 +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 w3+AeYvEbsCO; Wed, 13 Aug 2014 21:40:51 +0200 (MEST) 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 422F3D9307; Wed, 13 Aug 2014 21:40:51 +0200 (MEST) Message-ID: <53EBBF42.2010204@tik.ee.ethz.ch> Date: Wed, 13 Aug 2014 21:40:50 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mirja Kuehlewind , Nandita Dukkipati , "Scheffenegger,,> Richard" , Jana Iyengar , Bob Briscoe , ",> Matt Mathis" , "conex@ietf.org" References: <201408111431.29469.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201408111431.29469.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/-vVv6zG_O08Ex66OP5NrF7_dRQs Subject: Re: [conex] Fwd: Feedback on draft-ietf-conex-tcp-modifications-05 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, 13 Aug 2014 19:40:58 -0000 Hi Nandita, thanks a lot for your review. Please see comments in-line. > (feedback as individual contributor) > > No need to sugar coat: this draft needs lot more work. But happy to > help to shape it to its final form. > > --------- > > Table of Contents > > * Section 2 is Sender side changes. I was looking for equivalent > Receiver side changes, but there's no section for that. Should there > be one? There used to be receiver-side changes but as we move the accECN feedback to tcpm, no changes at the receiver are needed anymore. I added one sentence to explain this in the intro. > > * Section 3 My suggestion is to swap the ECN and loss detection > sections, because loss detection methods are implicit and can be used > today, while ECN requires... well ECN to be deployed. yes, will do > > Introduction > > * At the end of Introduction lay out the organization of the remainder > of the draft so a reader is informed of how the flow looks like. I would say all the text is already there but I now added references to the respective section in the intro. > > * Need to set up the problem being addressed > Jumping to Section 2 on Sender side modifications felt abrupt. What's > missing is a setup of the problem that the draft is proposing TCP > changes for. Can we place this problem setup either in the Intro. or a > separate section in itself. An example of what might go into the > problem set up is: Algorithms for a ConEx sender to keep track of byte > wise congestion. Isn't that given by the first paragraph: "This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP)." In fact the whole intro is only explaining what to expect in the rest of the doc. I hope that the changes I now applied help to make the structure more clear (incl. references to the following section) ... > > Section 2. Sender-side modifications > > * "A ConEx sender MUST negotiate for both SACK and ECN.... Thus a > ConEx SHOULD also implement SACK and ECN". > The para appears incorrect to me. If you mandate a MUST for SACK/ECN > negotiation, then shouldn't there be a MUST also for implementing SACK > and ECN? The point is that the ... you left out says "if available at the sender". Which means that if you have implemented SACK and ECN, you MUST use it. But if there are good reasons for you to implement ConEx but not SACK or ECN, you can still use ConEx. Howover, if you implement ConEx, you SHOULD also implemented SACK and ECN because otherwise it doesn't work that well. So I think the text is correct. Should I re-phase it to make it more clear? Do you have a concrete proposal? > > * Pseudo code. > Section 2 begs for pseudo code to succinctly describe the proposal. > Else the text is unnecessarily wordy. Sorry I don't see how to put pseudo code in this section because it only specifies all the MUSTs and SHOULDs but does not give any concrete algorithms. All detailed algorithms are in the next to sections. Do you have a proposal otherwise? > > * Section 2 ends abruptly. It sets up the problem and I was looking > for more details, but I guess they are punted to the other sections in > the draft. Yes. I hope that is more clear in the intro now but there is also the last paragraph that basically says that all the details are given in the next section: "The congestion accounting for each operation mode is described in the next section and the handling of the IPv6 bits itself in the subsequent section afterwards." What else would you like to see? > > Section 3. Accounting congestion > > * "... ConEx marked either with the E bit or the L bit..." > AFAICT this is the first occurrence of E and L bits, and hence should > define them. There used to be the reference to the CDO draft in the intro which i moved at some point to section 4. But you are right as I need the bits already here, I now moved it back into the intro. > > * Section 3 uses "outstanding bytes" often to describe the algorithms. > On immediate reading it was confusing, because in TCP implementations > outstanding bytes refers to the data that's been sent out but not > ACKed yet. Any suggestion how to change this? Or is it just you that confuses this? > > What you really mean by outstanding bytes here is a count of the > remaining bytes that are yet to be ConEx marked with either ECN or > loss bits. It's worthwhile having an explicitly and precisely efined > term here. The first paragraph says: "These counters hold the number of outstanding bytes that should be ConEx marked either with the E bit or the L bit in subsequent packets." Don't you think that is defined well enough? > > Section 3.1 > > * The algorithmic description of DeliveredData is laborious. Can you > see if you can simplify the description. Also take a look at [PRR RFC] > and see how DeliveredData is described there. This description was taken from PRR but is more detailed. I would definitely prefer to have a detailed equation here than just a description as in RFC PPR. I don't think it can be simplified. But I believe in case you actually sit there and implement ConEx it is less laborious. Or can you provide a concrete proposal how to describe this in a simpler way? > > * Is Section 3.1 the best place to describe DeliveredData? > DeliveredData is trivial when there's no loss - it's just the number > of bytes acked. So clearly the value of DeliveredData is when there > are packet losses. So then shouldn't you be describing in the loss > sesction and using that definition in the ECN section. As we do not use DeliveredData in the loss section, why should we describe it there? > > This also goes back to an earlier comment I made that you should > consider swapping the two placement of these two sections, 3.1 and > 3.2. > > * For ease of reading and simplicity, please split up the equation for > DeliveredData into the SACK and non-SACK case. I've move the equation up and inserted more paragraph breaks in the text, but I'm not sure how you would like to change the equation itself? > > Section 3.1.2 Classic ECN support > > * ".... it will receive one full RTT of delayed ACKs with the ..." > I don't remember exactly, but some implementations may disable delayed > ACKs on receiving a CE mark. What's the significance of mentioning > delayed ACKs here? ack, removed 'delayed'. > > * Why not recommend (SHOULD?) to turn off delayed ACKs when rceiving > CE marks. May be this belongs to another draft and not here? It does not really help the problem that much to turn of delayed ACKs; plus you might not want to turn it oft if there is already congestion; it would be necessary to implement a more accurate ECN feedback though but that's an own draft. Anyway, remember as we do not have a negotiation to use conex this document should be sender-side changes only. > > * The description of the more sophisticated heuristic to extract > congestion notification at the end of Section 3.1.2 sounds half > hearted to me. My suggestion: either describe it nicely and clearly > with pseudo code etc., or give a high level idea here and ditch the > details to an Appendix. At least that way the flow of the draft is > maintained. I don't really want to give pseudo code for this because than you have to introduce quite a lot state information. In fact our goal still is to name this option but not to encourage people to actually implement it and instead hopefully use a more accurate ECN feedback in future. > > Section 3.2 Loss Detection > > * Do retransmitted packets carry ConEx L bit or just the original data > segments? Whatever the answer is, why? The original data cannot carry the bit because at this point of time the packet was not lost yet...? So in most cases as the next packet you sent after detecting a loss is the retransmission and you what to send the ConEx signal as timely as possible, the retransmission will be L marked. But there is no need to bundle this. That's why it is not explicitly stated (anymore) because it just doesn't matter. > > Section 3.2.1 Without SACK Support > > * Isn't this the right place to discuss DeliveredData w/o SACK support? Why? You don't need it here as we simply look at the size of the retransmit. > > Section 3.2.1 Without SACK support > > * General comment that's not sepcific to this section: LEC and LEG are > very close in naming, but mean different things. Can we coose better > names? Yes I also though about it, but couldn't come up with a better name yet. Do you have a proposal? > > * Is there any implicit relation between LEC and LEG counters? Seems > like there is, otherwise why do you say that LEG shoul be increased by > LEC? I don't really understand your question...? > > * It seems to me that you have a nice algorithm here, but sorry you > totally lost me. My only suggestion would be to try and put the algo > in a nice pseudo code. Will think about it... > > Section 4 > > * A lot of what appears in this section seems like should be in the > sendder side changes. Of course it is all sender side changes but section 2 just describes the specification with MUSTs and SHOULDS while section 3 and 4 give more details. Of course section 2 already says that all these things need to be done but on a high level. You cannot move this section though because you need to explain LEG/CEG first which is done in section 3. > > Section 4.1 > > * What's the reasoning behind: "If the CEG or LEG counter is negative, > the respective counter SHOULD be reset to sero within one RTT after it > was decreased..." Because congestion is timely information which is outdated after one RTT. Do I need to add this reasoning here, because for me that was really obvious and it is more elaborated in section 6 as well... > > Section 4.2 > > * Please clarify the relation between credit counter and the previous > counters LEG/LEC? Are they independent? yes independent. But i don't think this should be further explained here because you should rather read the abstract mechanism doc or auditing doc instead. > > * Could you expand more on how you arrived at: every fourth packet > will allow teh respective number of credits in Slow Start..." I can > see how it works. Is there a formulae connecting the Slow Start > exponent and the the nth packet that needs to be marked? yes and no; it's just because you double your window in Slow Start. So you have already halve the packets marked form the old window in the previous RTT and you have to marked halve the packet of the total increase in this RTT, which is one quarter of the window at the end of this RTT - thus every fourth packet. But there is not really a formula... do you think there is further explanation needed? Because if you take a little time to think about it, it easy to figure that out. > > * Mention how credits should be replenished in congestion avoidance phase. That's the second paragraph: "The number of credits sent should always equal the number of bytes in flight, as all packets could potentially get lost or congestion marked. Thus a ConEx sender should monitor the number of bytes in flight f. If f ever becomes larger than c, the ConEx sender SHOULD send new credits. Remember that c will be decreased if congestion occurs. " That's simply true in Congestion Avoidance as well as in Slow Start. But in Slow Start this will usually lead to a (too) large number of credits sent therefore (if you want to take the risk to potentially but very rarely have sent to less credits) you can use the proposed algorithm in Slow Start. I can make this point more clear if you think that's not clear enough. > > Section 6 Timeliness of the ConEx Signals > > * You discuss the event when receiving both ECN and loss signals. But > how should the sender respond? Send ConEx signals for summation of > both ECN/loss (I would think not) or choose the max? I'm not sure I understand your question but you have to reflect all congestion feedback you get. To detect loss and get ECN feedback at the time is a valid case thus you have to increase both counters and sent E as well as L marks. What exactly was your question? Thanks! Mirja > > Editorial changes > > I have tons of editorial changes marked all over the draft - too many > to spend time to cut+paste in this email. I'll just scan the sheets > and send them to you. > > ------------------------------------------------------- > -- ------------------------------------------ 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 Thu Aug 14 09:41:53 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 A358F1A0747 for ; Thu, 14 Aug 2014 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.558 X-Spam-Level: X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, T_TVD_FUZZY_SECURITIES=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 09UZoL26swbW for ; Thu, 14 Aug 2014 09:41:49 -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 5EC1F1A04B7 for ; Thu, 14 Aug 2014 09:41:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8328DD9303; Thu, 14 Aug 2014 18:41:46 +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 21tQnMp64YJW; Thu, 14 Aug 2014 18:41:46 +0200 (MEST) 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 484B6D9302; Thu, 14 Aug 2014 18:41:46 +0200 (MEST) Message-ID: <53ECE6C9.40300@tik.ee.ethz.ch> Date: Thu, 14 Aug 2014 18:41:45 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> In-Reply-To: <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/8P2Kdjaj8L5qhylJjxHSLhFqTVs Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 14 Aug 2014 16:41:52 -0000 Hi Bob, see inline >>> * Added subsection of intro on experiment goals: criteria for success >>> and duration >> >> I believe most of the text actually should go in the tcp mods draft. I >> not sure if there is a common sense in the mean time to have such a >> section in very exp document. But if not I would rather not have it in >> this document because I'm not sure how to define if an experiment was >> successful. If fact the CDO is the only approach at could fulfill our >> requirements, so there is no other option. And if the coding itself >> with the four bits is useful or not, is not really a question of this >> document, but amybe more of the whole mechanism (incl. auditing and >> policing) or maybe the tcp mods document...? > > The solution to this would be to refer to one doc that has the expt > goals. However, I believe each doc can be seen as a separate piece of a > bigger expt. > * The expt that this doc describes is a choice of encoding (see below - > there are other choices). > * The main expt that the TCP doc describes is how to set credit. So is it okay if I just add one sentence in the intro (instead of having an own section): "This specification is experimental to allow the IETF to assess whether the decision to implement the ConEx signal as a destination option fulfills the requirements stated in this document, as well as to evaluate the proposed encoding of the ConEx signals." Does this work for you? >>> ==Requirements== >>> >>> * Referred to abstract-mech for requirements, explained that it would >>> be hard to satisfy them all, and explained which one wasn't satisfied >>> (visibility in outer), referring to section on fast-path performance. >> >> Took over some of your text at the beginning of this section (and also >> reused some text we already used to have there). >> >> Do you really think that the two requirements you've added are needed? >> Because both basically say that the ConEx coding should encode the >> Conex signal, which is, from my point of view, the whole purpose of >> this document. > > Perhaps you're too close to ConEx. If these reqs hadn't been defined in > abstract-mech, you wouldn't know what "the ConEx signal" was. These reqs > say what the component parts of the ConEx signal are. It could say you > need separate signals for ECN-credit and loss-credit. It could say ConEx > nodes must successfully negotiate ECN (then re-ECN would be a solution). > > The alternative is to refer to abstract-mech for all the requirements > and not list them here, or list the reqs in abstract-mech that are > relevant to the network layer encoding. > >> I do have the feeling that the other requirements listed here are on a >> slightly different level because they are more related to deployment >> issues. > > You could say that (but you don't). That's why it seemed odd that you > listed some requirements, but not the basic ones. Okay the intent of these requirements was not to rephrase what is already written down in the abstract-mech because I assume that people reading this document do not really care why the conex signals look as they do but just want to know which conex signals are there (and what there meaning is). The reason to have the requirement listed is simply to justify the potentially awkward choice to encode them in a destination option. I now have the following text: "A set of requirement for an ideal concrete ConEx wire protocol is given in . In the ConEx working group is was recognized that it will be difficult to find an encoding in IPv6 that satisfies all requirements. The choice in this document to implement the ConEx information in a destination option satisfies most of those requirements, briefly summarized below:" + I added your paragraph on visibility at the end. Okay? >> And regarding tunneling: you are right that we need to give more >> advise on tunneling. Shouldn't we just say that one MUST copy the >> inner ConEx Option to the outer header (to solve the visibility problem)? > > You can't say MUST, because IPv6 dest opts are meant to be e2e only, so > no IPv6 tunnel currently even understands what a dest opt is, let alone > copies any dest opt to the outer. A MUST would ring huge alarm bells in > the vendor community. > > I added it as a MAY, purely because it might be considered a performance > optimisation. I'm still worried about the size of the alarm bells that > will ring. It could prevent this draft progressing thru the IESG. Suresh > will know best how this might be received in the IESG. Okay, got it; see further below... > > >>> ==CDO== >> >>> * Specified precisely which IP header is included in the byte count. >> So you suggest to not include any options? > > I didn't say that, did I? If the wording I used is ambiguous, pls fix it. > >> Why? I'd say you either include all bits because all of them >> contribute to congestion, or none of the IP header bits because that's >> just the overhead you can't avoid if you what to send anything. Also >> of course you can generate a larger percentage of overhead if you send >> smaller packets. > > That's why I think it is reasonable to include the IP header (and its > options) that immediately encapsulates the ConEx dest opt. Okay I misread your text. I just though, if you detect a CDO in the header you are currently looking at, you will simply look at the playload length and next hop fields of this header and than add another 40 bytes for the header itself. But in fact that might be wrong if you have another IP header encapsulated in the payload... so what is actually the right number of bytes here? I was about to write the following but I'm not sure if that is actually write and/or clear: "... IP packet (including the IP header that carries the CDO and all associated options)..."? That just doesn't say if you should look what the next header is and subtract all other IP header bytes you can find. Is this needed? >>> * Suggested deleting example of Not-ConEx-capable packets (see >>> separate thread to conex-tcp-modifications authors about TCP pure ACKs). >> I can remove the example but not sure why you are suggesting this. If >> you actually imply that the X bit should never be zero that we have to >> discuss if the X bit is needed at all. > > I have never thought the X flag was needed. There's probably some email > on the list somewhere in the past from me that says that. > > As I put in one of the comment bubbles: > "The only need I can see for the X-flag is if > the Reserved field gets used in future for > something in addition to ConEx. Then there > would be a need to identify packets that > are not ConEx-capable but still carry the > CDO option (for the new reason)." > > Can anyone think of a use for the X flag? I thought the X bit unset means: I'm a ConEx aware sender and i want to follow the rules but I don't have any feedback for this (control) data so I'm unable to give you useful ConEx information and if you use this packet for your estimation of the current congestion level, you might underestimate it. Doesn't that make sense...? >>> ==Fast-path== >>> >>> * CDO as first destination option: changed from MUST to SHOULD (with >>> an example of when not to). >> I believe this really needs to be a MUST. I know that might restrict >> the use of ConEx with potential other options that might have the same >> requirement (for different reasons). But if you don't put a MUST here, >> you cannot implemented the suggested way in the fast path. > > A SHOULD still means it will be the first option in all current > implementations. However, I suggest a SHOULD, precisely because > performance reasons are not absolute, so they don't require a MUST. If > another dest opt cannot work at all unless it is first, that would be a > valid reason for CDO coming second, because it still works, it's /just/ > slower. > > The IESG will (rightly) be very wary of any draft that says an option > MUST be the first option. > > I suggested the following text after this: "(This is not > stated as a 'MUST', because some future destination option might need to > be placed first for functional rather than just performance reasons.)" So our fast path implementation must simply assume that there is no CDO in case it cannot find it as the first option. Otherwise all non-ConEx packets would need to go to the slow path to make sure there is no ConEx option. That means to me that this must be a MUST...? >>> ==IPsec compatibility== >>> >>> * Suggested ConEx counts the AH header, and the outer tunnel mode >>> header, with reasoning. >> Yes, need to be more precise. Will add. > > This one wasn't just clarity. I've actually contradicted what was said, > so pls make sure there wasn't a good reason for why it was like it was. > > I was most concerned about suggesting this change, because it was the > only one that caused a technical difference. Ohh, I didn't read your comments carefully and was just looking at the text changes... this whole accounting is a mess :-( Maybe we should only account the IPv6 header itself and the destination options...? Moreover, isn't this here the same case than with tunneling in general. Only if the node that does the encapsulation is ConEx-aware it can copy the CDO, otherwise it will be not visible anymore. So this should either be a should, or we have to say something like: if the node is ConEx-aware is MUST copy the CDO...? > > > >>> * Suggested the section is restructured because I believe the >>> visibility problem is not related to tunnel mode, but only to ESP in >>> tunnel mode. >> I agree that tunneling was not addressed well. >> >>> >>> * Added a para about the possibility of implementing a ConEx proxy >>> (without breaking e2e authentication). >> ACK will add. >> >>> >>> ==Tunnelling== >>> >>> * Section added, to generalise from just IPsec to any IP-in-IP >>> tunnelling (particularly relevant to mobile scenarios). >> If we have a separate section on tunneling. Shouldn't we have tunning >> first and then IPSec...? > > Could do, I guess. > > > >>> * Suggested optional copying of CDO to outer, but also a simpler 'Do >>> not copy CDO' alternative. >> I don't really get you SHOULD NOT but MAY here...? > > See earlier. Tunnels don't normally understand dest opts, which is why I > said SHOULD NOT. But the MAY is a performance optimisation. Am I helping? > > > >>> ==Security Considerations== >>> >>> * Added lots, all pointers to where security issues are discussed in >>> other places (which is what security directorate reviewers need). >> Okay I can add that if you think it's necessary (I would say it's just >> redundant, but you be might right that it just helps the sec dir). > > It's not always obvious which aspects relate to security. Especially > when the security is structural rather than crypto. So I think these > sentences are useful to sec dir. > > >>> ==IANA== >>> >>> * I think the act bits need to be 00 not 10 to avoid ConEx packets >>> being dropped by non-ConEx nodes (including by non-ConEx receivers)? >>> But I'm willing to be corrected. >> I agree; Will ask Suresh why he has put a 10 though. > > Yes, he's the right guy to check with. > > > Bob > > >> Thanks, >> Mirja >> >>> >>> >>> Regards >>> >>> >>> >>> >>> Bob > > {Note 1} > For anyone watching on the list, the tentative idea that Mirja has > reminded me of is documented in 11.3.1 of my PhD thesis entitled "Covert > Markings as a Policer Signal". > > The potential problem: A ConEx policer punishes punishment. If a > congestion policer starts dropping packets because the user has > contributed excessively to congestion, in subsequent rounds the user has > to re-echo 'L' markings for the policer drops as well. This can drive > the policer further into 'debit'. This might make it difficult for the > user to get out of trouble once she's started getting into trouble. > > The basic idea was that when a congestion policer drops packets (because > the user is causing more congestion than her allowance), it will also > remove ConEx markings. Then (if there is some way for the receiver to > feed this back), the sender knows not to send more ConEx marks because > these aren't congestion drops, they are policer drops. > > We didn't that double punishment made it hard to get out of trouble in > any policer experiments so far, so let's not allow for a possible > solution to a problem that we probably don't even have. The current crop > of ConEx drafts are experimental anyway. If this problem does surface, > then we can reconsider. > > > > > > ________________________________________________________________ > Bob Briscoe, BT > -- ------------------------------------------ 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 Thu Aug 14 09:51:49 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 F01041A08B6 for ; Thu, 14 Aug 2014 09:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.558 X-Spam-Level: X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, T_TVD_FUZZY_SECURITIES=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 m6rDhkK8bSf6 for ; Thu, 14 Aug 2014 09:51:44 -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 944011A0747 for ; Thu, 14 Aug 2014 09:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0D170D9303; Thu, 14 Aug 2014 18:51:37 +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 3Jqh3B8sbrdu; Thu, 14 Aug 2014 18:51:36 +0200 (MEST) 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 B5764D9302; Thu, 14 Aug 2014 18:51:36 +0200 (MEST) Message-ID: <53ECE917.6000803@tik.ee.ethz.ch> Date: Thu, 14 Aug 2014 18:51:35 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch> In-Reply-To: <53ECE6C9.40300@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/_HBG4ExEr1-Gw_FRrGsL2u5LMQA Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 14 Aug 2014 16:51:47 -0000 Hi again, sorry; pressed sent without being done... see further below.... On 14.08.2014 18:41, Mirja Kühlewind wrote: > Hi Bob, > > see inline > >>>> * Added subsection of intro on experiment goals: criteria for success >>>> and duration >>> >>> I believe most of the text actually should go in the tcp mods draft. I >>> not sure if there is a common sense in the mean time to have such a >>> section in very exp document. But if not I would rather not have it in >>> this document because I'm not sure how to define if an experiment was >>> successful. If fact the CDO is the only approach at could fulfill our >>> requirements, so there is no other option. And if the coding itself >>> with the four bits is useful or not, is not really a question of this >>> document, but amybe more of the whole mechanism (incl. auditing and >>> policing) or maybe the tcp mods document...? >> >> The solution to this would be to refer to one doc that has the expt >> goals. However, I believe each doc can be seen as a separate piece of a >> bigger expt. >> * The expt that this doc describes is a choice of encoding (see below - >> there are other choices). >> * The main expt that the TCP doc describes is how to set credit. > So is it okay if I just add one sentence in the intro (instead of having > an own section): > > "This specification is experimental to allow the IETF to assess whether > the decision to implement the ConEx signal as a destination option > fulfills the requirements stated in this document, as well as to > evaluate the proposed encoding of the ConEx signals." > > Does this work for you? > >>>> ==Requirements== >>>> >>>> * Referred to abstract-mech for requirements, explained that it would >>>> be hard to satisfy them all, and explained which one wasn't satisfied >>>> (visibility in outer), referring to section on fast-path performance. >>> >>> Took over some of your text at the beginning of this section (and also >>> reused some text we already used to have there). >>> >>> Do you really think that the two requirements you've added are needed? >>> Because both basically say that the ConEx coding should encode the >>> Conex signal, which is, from my point of view, the whole purpose of >>> this document. >> >> Perhaps you're too close to ConEx. If these reqs hadn't been defined in >> abstract-mech, you wouldn't know what "the ConEx signal" was. These reqs >> say what the component parts of the ConEx signal are. It could say you >> need separate signals for ECN-credit and loss-credit. It could say ConEx >> nodes must successfully negotiate ECN (then re-ECN would be a solution). >> >> The alternative is to refer to abstract-mech for all the requirements >> and not list them here, or list the reqs in abstract-mech that are >> relevant to the network layer encoding. >> >>> I do have the feeling that the other requirements listed here are on a >>> slightly different level because they are more related to deployment >>> issues. >> >> You could say that (but you don't). That's why it seemed odd that you >> listed some requirements, but not the basic ones. > Okay the intent of these requirements was not to rephrase what is > already written down in the abstract-mech because I assume that people > reading this document do not really care why the conex signals look as > they do but just want to know which conex signals are there (and what > there meaning is). > The reason to have the requirement listed is simply to justify the > potentially awkward choice to encode them in a destination option. > > I now have the following text: > > "A set of requirement for an ideal concrete ConEx wire protocol is given > in . In the ConEx working > group is was recognized that it will be difficult to find an encoding in > IPv6 that satisfies all requirements. The choice in this document to > implement the ConEx information in a destination option satisfies most > of those requirements, briefly summarized below:" > > + I added your paragraph on visibility at the end. > > Okay? > >>> And regarding tunneling: you are right that we need to give more >>> advise on tunneling. Shouldn't we just say that one MUST copy the >>> inner ConEx Option to the outer header (to solve the visibility >>> problem)? >> >> You can't say MUST, because IPv6 dest opts are meant to be e2e only, so >> no IPv6 tunnel currently even understands what a dest opt is, let alone >> copies any dest opt to the outer. A MUST would ring huge alarm bells in >> the vendor community. >> >> I added it as a MAY, purely because it might be considered a performance >> optimisation. I'm still worried about the size of the alarm bells that >> will ring. It could prevent this draft progressing thru the IESG. Suresh >> will know best how this might be received in the IESG. > Okay, got it; see further below... > >> >> >>>> ==CDO== >>> >>>> * Specified precisely which IP header is included in the byte count. >>> So you suggest to not include any options? >> >> I didn't say that, did I? If the wording I used is ambiguous, pls fix it. >> >>> Why? I'd say you either include all bits because all of them >>> contribute to congestion, or none of the IP header bits because that's >>> just the overhead you can't avoid if you what to send anything. Also >>> of course you can generate a larger percentage of overhead if you send >>> smaller packets. >> >> That's why I think it is reasonable to include the IP header (and its >> options) that immediately encapsulates the ConEx dest opt. > Okay I misread your text. > > I just though, if you detect a CDO in the header you are currently > looking at, you will simply look at the playload length and next hop > fields of this header and than add another 40 bytes for the header > itself. But in fact that might be wrong if you have another IP header > encapsulated in the payload... so what is actually the right number of > bytes here? > > I was about to write the following but I'm not sure if that is actually > write and/or clear: > "... IP packet (including the IP header that carries the CDO and all > associated options)..."? > That just doesn't say if you should look what the next header is and > subtract all other IP header bytes you can find. Is this needed? > > >>>> * Suggested deleting example of Not-ConEx-capable packets (see >>>> separate thread to conex-tcp-modifications authors about TCP pure >>>> ACKs). >>> I can remove the example but not sure why you are suggesting this. If >>> you actually imply that the X bit should never be zero that we have to >>> discuss if the X bit is needed at all. >> >> I have never thought the X flag was needed. There's probably some email >> on the list somewhere in the past from me that says that. >> >> As I put in one of the comment bubbles: >> "The only need I can see for the X-flag is if >> the Reserved field gets used in future for >> something in addition to ConEx. Then there >> would be a need to identify packets that >> are not ConEx-capable but still carry the >> CDO option (for the new reason)." >> >> Can anyone think of a use for the X flag? > I thought the X bit unset means: I'm a ConEx aware sender and i want to > follow the rules but I don't have any feedback for this (control) data > so I'm unable to give you useful ConEx information and if you use this > packet for your estimation of the current congestion level, you might > underestimate it. > > Doesn't that make sense...? > > >>>> ==Fast-path== >>>> >>>> * CDO as first destination option: changed from MUST to SHOULD (with >>>> an example of when not to). >>> I believe this really needs to be a MUST. I know that might restrict >>> the use of ConEx with potential other options that might have the same >>> requirement (for different reasons). But if you don't put a MUST here, >>> you cannot implemented the suggested way in the fast path. >> >> A SHOULD still means it will be the first option in all current >> implementations. However, I suggest a SHOULD, precisely because >> performance reasons are not absolute, so they don't require a MUST. If >> another dest opt cannot work at all unless it is first, that would be a >> valid reason for CDO coming second, because it still works, it's /just/ >> slower. >> >> The IESG will (rightly) be very wary of any draft that says an option >> MUST be the first option. >> >> I suggested the following text after this: "(This is not >> stated as a 'MUST', because some future destination option might need to >> be placed first for functional rather than just performance reasons.)" > So our fast path implementation must simply assume that there is no CDO > in case it cannot find it as the first option. Otherwise all non-ConEx > packets would need to go to the slow path to make sure there is no ConEx > option. That means to me that this must be a MUST...? > > >>>> ==IPsec compatibility== >>>> >>>> * Suggested ConEx counts the AH header, and the outer tunnel mode >>>> header, with reasoning. >>> Yes, need to be more precise. Will add. >> >> This one wasn't just clarity. I've actually contradicted what was said, >> so pls make sure there wasn't a good reason for why it was like it was. >> >> I was most concerned about suggesting this change, because it was the >> only one that caused a technical difference. > Ohh, I didn't read your comments carefully and was just looking at the > text changes... this whole accounting is a mess :-( > Maybe we should only account the IPv6 header itself and the destination > options...? > > Moreover, isn't this here the same case than with tunneling in general. > Only if the node that does the encapsulation is ConEx-aware it can copy > the CDO, otherwise it will be not visible anymore. > > So this should either be a should, or we have to say something like: if > the node is ConEx-aware is MUST copy the CDO...? And then we can the same thing for tunneling in general...? >> >>>> * Suggested optional copying of CDO to outer, but also a simpler 'Do >>>> not copy CDO' alternative. >>> I don't really get you SHOULD NOT but MAY here...? >> >> See earlier. Tunnels don't normally understand dest opts, which is why I >> said SHOULD NOT. But the MAY is a performance optimisation. Am I helping? Okay, understood. But why SHOULD NOT? Isn't it sufficient to say MAY...? (or even MUST/SHOULD if ConEx-aware...?) Mirja >>>> ==Security Considerations== >>>> >>>> * Added lots, all pointers to where security issues are discussed in >>>> other places (which is what security directorate reviewers need). >>> Okay I can add that if you think it's necessary (I would say it's just >>> redundant, but you be might right that it just helps the sec dir). >> >> It's not always obvious which aspects relate to security. Especially >> when the security is structural rather than crypto. So I think these >> sentences are useful to sec dir. >> >> >>>> ==IANA== >>>> >>>> * I think the act bits need to be 00 not 10 to avoid ConEx packets >>>> being dropped by non-ConEx nodes (including by non-ConEx receivers)? >>>> But I'm willing to be corrected. >>> I agree; Will ask Suresh why he has put a 10 though. >> >> Yes, he's the right guy to check with. >> >> >> Bob >> >> >>> Thanks, >>> Mirja >>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> >>>> Bob >> >> {Note 1} >> For anyone watching on the list, the tentative idea that Mirja has >> reminded me of is documented in 11.3.1 of my PhD thesis entitled "Covert >> Markings as a Policer Signal". >> >> The potential problem: A ConEx policer punishes punishment. If a >> congestion policer starts dropping packets because the user has >> contributed excessively to congestion, in subsequent rounds the user has >> to re-echo 'L' markings for the policer drops as well. This can drive >> the policer further into 'debit'. This might make it difficult for the >> user to get out of trouble once she's started getting into trouble. >> >> The basic idea was that when a congestion policer drops packets (because >> the user is causing more congestion than her allowance), it will also >> remove ConEx markings. Then (if there is some way for the receiver to >> feed this back), the sender knows not to send more ConEx marks because >> these aren't congestion drops, they are policer drops. >> >> We didn't that double punishment made it hard to get out of trouble in >> any policer experiments so far, so let's not allow for a possible >> solution to a problem that we probably don't even have. The current crop >> of ConEx drafts are experimental anyway. If this problem does surface, >> then we can reconsider. >> >> >> >> >> >> ________________________________________________________________ >> Bob Briscoe, BT >> > -- ------------------------------------------ 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 Thu Aug 14 12:15:49 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 5288E1A045A for ; Thu, 14 Aug 2014 12:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 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.668, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=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 YujrCzgTDhpX for ; Thu, 14 Aug 2014 12:15:41 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B294C1A0292 for ; Thu, 14 Aug 2014 12:15:40 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 14 Aug 2014 20:15:34 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 14 Aug 2014 20:15:38 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 14 Aug 2014 20:15:35 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.26.130]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7EJFVI8000808; Thu, 14 Aug 2014 20:15:31 +0100 Message-ID: <201408141915.s7EJFVI8000808@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Aug 2014 20:15:31 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <53ECE917.6000803@tik.ee.ethz.ch> References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch> <53ECE917.6000803@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/6Z279HwVJfrwAYrQ9csqMicY7b0 Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 14 Aug 2014 19:15:45 -0000 Mirja, At 17:51 14/08/2014, Mirja K=FChlewind wrote: >Hi again, > >sorry; pressed sent without being done... see further below.... > >On 14.08.2014 18:41, Mirja K=FChlewind wrote: >>Hi Bob, >> >>see inline >> >>>>>* Added subsection of intro on experiment goals: criteria for success >>>>>and duration >>>> >>>>I believe most of the text actually should go in the tcp mods draft. I >>>>not sure if there is a common sense in the mean time to have such a >>>>section in very exp document. But if not I would rather not have it in >>>>this document because I'm not sure how to define if an experiment was >>>>successful. If fact the CDO is the only approach at could fulfill our >>>>requirements, so there is no other option. And if the coding itself >>>>with the four bits is useful or not, is not really a question of this >>>>document, but amybe more of the whole mechanism (incl. auditing and >>>>policing) or maybe the tcp mods document...? >>> >>>The solution to this would be to refer to one doc that has the expt >>>goals. However, I believe each doc can be seen as a separate piece of a >>>bigger expt. >>>* The expt that this doc describes is a choice of encoding (see below - >>>there are other choices). >>>* The main expt that the TCP doc describes is how to set credit. >>So is it okay if I just add one sentence in the intro (instead of having >>an own section): >> >>"This specification is experimental to allow the IETF to assess whether >>the decision to implement the ConEx signal as a destination option >>fulfills the requirements stated in this document, as well as to >>evaluate the proposed encoding of the ConEx signals." >> >>Does this work for you? Why resist the good practice of defining full=20 criteria for success and duration of experiment?=20 This doc (not TCP) is the primary basis of any=20 ConEx experiment. I don't mind if it's not in a=20 separate section, but these elements should be in an expt RFC. I think "requirements in abstract-mech" would be more objective. I would like it recorded somewhere that it=20 is going to take many years to find a scenario=20 where a v6-only experiment in traffic management=20 (on a tiny %age of the traffic) makes any sense=20 whatsoever. It will be near-impossible to measure whether there is any= benefit. >>>>>=3D=3DRequirements=3D=3D >>>>> >>>>>* Referred to abstract-mech for requirements, explained that it would >>>>>be hard to satisfy them all, and explained which one wasn't satisfied >>>>>(visibility in outer), referring to section on fast-path performance. >>>> >>>>Took over some of your text at the beginning of this section (and also >>>>reused some text we already used to have there). >>>> >>>>Do you really think that the two requirements you've added are needed? >>>>Because both basically say that the ConEx coding should encode the >>>>Conex signal, which is, from my point of view, the whole purpose of >>>>this document. >>> >>>Perhaps you're too close to ConEx. If these reqs hadn't been defined in >>>abstract-mech, you wouldn't know what "the ConEx signal" was. These reqs >>>say what the component parts of the ConEx signal are. It could say you >>>need separate signals for ECN-credit and loss-credit. It could say ConEx >>>nodes must successfully negotiate ECN (then re-ECN would be a solution). >>> >>>The alternative is to refer to abstract-mech for all the requirements >>>and not list them here, or list the reqs in abstract-mech that are >>>relevant to the network layer encoding. >>> >>>>I do have the feeling that the other requirements listed here are on a >>>>slightly different level because they are more related to deployment >>>>issues. >>> >>>You could say that (but you don't). That's why it seemed odd that you >>>listed some requirements, but not the basic ones. >>Okay the intent of these requirements was not to rephrase what is >>already written down in the abstract-mech because I assume that people >>reading this document do not really care why the conex signals look as >>they do but just want to know which conex signals are there (and what >>there meaning is). >>The reason to have the requirement listed is simply to justify the >>potentially awkward choice to encode them in a destination option. >> >>I now have the following text: >> >>"A set of requirement for an ideal concrete ConEx wire protocol is given >>in . In the ConEx working >>group is was recognized that it will be difficult to find an encoding in >>IPv6 that satisfies all requirements. The choice in this document to >>implement the ConEx information in a destination option satisfies most >>of those requirements, briefly summarized below:" >> >>+ I added your paragraph on visibility at the end. >> >>Okay? How about not including the 2 extra requirements=20 and changing your last sentence now I understand what you want to say: "The choice in this document to implement the=20 ConEx information in a destination option aims to=20 satisfy those requirements that constrain the placement of ConEx= information:" >>>>And regarding tunneling: you are right that we need to give more >>>>advise on tunneling. Shouldn't we just say that one MUST copy the >>>>inner ConEx Option to the outer header (to solve the visibility >>>>problem)? >>> >>>You can't say MUST, because IPv6 dest opts are meant to be e2e only, so >>>no IPv6 tunnel currently even understands what a dest opt is, let alone >>>copies any dest opt to the outer. A MUST would ring huge alarm bells in >>>the vendor community. >>> >>>I added it as a MAY, purely because it might be considered a performance >>>optimisation. I'm still worried about the size of the alarm bells that >>>will ring. It could prevent this draft progressing thru the IESG. Suresh >>>will know best how this might be received in the IESG. >>Okay, got it; see further below... >> >>> >>> >>>>>=3D=3DCDO=3D=3D >>>> >>>>>* Specified precisely which IP header is included in the byte count. >>>>So you suggest to not include any options? >>> >>>I didn't say that, did I? If the wording I used is ambiguous, pls fix it. >>> >>>>Why? I'd say you either include all bits because all of them >>>>contribute to congestion, or none of the IP header bits because that's >>>>just the overhead you can't avoid if you what to send anything. Also >>>>of course you can generate a larger percentage of overhead if you send >>>>smaller packets. >>> >>>That's why I think it is reasonable to include the IP header (and its >>>options) that immediately encapsulates the ConEx dest opt. >>Okay I misread your text. >> >>I just though, if you detect a CDO in the header you are currently >>looking at, you will simply look at the playload length and next hop >>fields of this header and than add another 40 bytes for the header >>itself. But in fact that might be wrong if you have another IP header >>encapsulated in the payload... so what is actually the right number of >>bytes here? >> >>I was about to write the following but I'm not sure if that is actually >>write and/or clear: >>"... IP packet (including the IP header that carries the CDO and all >>associated options)..."? >>That just doesn't say if you should look what the next header is and >>subtract all other IP header bytes you can find. Is this needed? I'm happy with your something like your last=20 sentence. For precision I suggest rewording: IP packet (including the IP header that directly=20 encapsulates the CDO and everything that IP header encapsulates). It doesn't have to go searching for any more=20 deeply encapsulated CDO. If there is one, that=20 will be dealt with by whatever higher layer it=20 was written in, at the point when the outer=20 layers have been peeled off and some function at=20 that higher layer is processing these inner dest opts. >>>>>* Suggested deleting example of Not-ConEx-capable packets (see >>>>>separate thread to conex-tcp-modifications authors about TCP pure >>>>>ACKs). >>>>I can remove the example but not sure why you are suggesting this. If >>>>you actually imply that the X bit should never be zero that we have to >>>>discuss if the X bit is needed at all. >>> >>>I have never thought the X flag was needed. There's probably some email >>>on the list somewhere in the past from me that says that. >>> >>>As I put in one of the comment bubbles: >>>"The only need I can see for the X-flag is if >>>the Reserved field gets used in future for >>>something in addition to ConEx. Then there >>>would be a need to identify packets that >>>are not ConEx-capable but still carry the >>>CDO option (for the new reason)." >>> >>>Can anyone think of a use for the X flag? >>I thought the X bit unset means: I'm a ConEx aware sender and i want to >>follow the rules but I don't have any feedback for this (control) data >>so I'm unable to give you useful ConEx information and if you use this >>packet for your estimation of the current congestion level, you might >>underestimate it. >> >>Doesn't that make sense...? Not to me. What does "feedback for this (control)=20 data" mean? Feedback is about a path used by a=20 5-tuple. This control data is about to be sent=20 over such a path. If the sender has feedback=20 about that path, the feedback applies to=20 everything sent over the path, at the IP layer,=20 whatever categorisation the next packet has at L4. (Even if control data is somehow being sent over=20 a different path, e.g. using MPTCP or something,=20 and there has never been feedback over that path,=20 then that would warrant Credit, not absence of ConEx.) >>>>>=3D=3DFast-path=3D=3D >>>>> >>>>>* CDO as first destination option: changed from MUST to SHOULD (with >>>>>an example of when not to). >>>>I believe this really needs to be a MUST. I know that might restrict >>>>the use of ConEx with potential other options that might have the same >>>>requirement (for different reasons). But if you don't put a MUST here, >>>>you cannot implemented the suggested way in the fast path. >>> >>>A SHOULD still means it will be the first option in all current >>>implementations. However, I suggest a SHOULD, precisely because >>>performance reasons are not absolute, so they don't require a MUST. If >>>another dest opt cannot work at all unless it is first, that would be a >>>valid reason for CDO coming second, because it still works, it's /just/ >>>slower. >>> >>>The IESG will (rightly) be very wary of any draft that says an option >>>MUST be the first option. >>> >>>I suggested the following text after this: "(This is not >>>stated as a 'MUST', because some future destination option might need to >>>be placed first for functional rather than just performance reasons.)" >>So our fast path implementation must simply assume that there is no CDO >>in case it cannot find it as the first option. Otherwise all non-ConEx >>packets would need to go to the slow path to make sure there is no ConEx >>option. That means to me that this must be a MUST...? OK, I see the problem, but how much of a=20 performance problem would it really be for the=20 fast path of a ConEx function to step along dest=20 opts until it gets to CDO then stops (rather than stop if CDO is not first)? Then "CDO SHOULD be first" would give no=20 different performance to "CDO MUST be first", if=20 CDO actually was first. If CDO had to be placed=20 second on a certain packet, "CDO SHOULD be first"=20 would take just one more op than "CDO MUST be first". Note: I've just re-read the spec of the IPv6=20 header. We need to specify that CDO goes in the=20 "Destination Options (before routing header)",=20 not the "Destination Options (before upper-layer=20 header)". Then it won't be encrypted by an ESP header. >>>>>=3D=3DIPsec compatibility=3D=3D >>>>> >>>>>* Suggested ConEx counts the AH header, and the outer tunnel mode >>>>>header, with reasoning. >>>>Yes, need to be more precise. Will add. >>> >>>This one wasn't just clarity. I've actually contradicted what was said, >>>so pls make sure there wasn't a good reason for why it was like it was. >>> >>>I was most concerned about suggesting this change, because it was the >>>only one that caused a technical difference. >>Ohh, I didn't read your comments carefully and was just looking at the >>text changes... this whole accounting is a mess :-( I don't think it has to be, if we keep to the rule we just agreed above. >>Maybe we should only account the IPv6 header itself and the destination >>options...? Why? I really don't understand why the IPsec=20 accounting was written like it was. Pls explain. >>Moreover, isn't this here the same case than with tunneling in general. >>Only if the node that does the encapsulation is ConEx-aware it can copy >>the CDO, otherwise it will be not visible anymore. >> >>So this should either be a should, or we have to say something like: if >>the node is ConEx-aware is MUST copy the CDO...? >And then we can the same thing for tunneling in general...? That's surely a circular argument. What would=20 make a tunnel endpoint into a ConEx-aware tunnel=20 endpoint, so that it would have to copy the CDO?=20 It would only become ConEx-aware if it had code=20 added to look for the CDO, and why would it have=20 that code added unless it was going to do=20 something with CDO? That's why I think my 'MAY=20 copy as a performance optimisation' formula is the best we can do. There is no point trying to fix the IPv6=20 facilities for tunnelling new extension headers.=20 The people whose job it was to design this didn't=20 do their job. Their design is now burned into=20 IPv6 hardware processors everywhere. Full stop. All we can hope to do is ensure that CDO is not=20 encrypted with ESP. That is feasible. Whatever we do, in many cases, the IPv6 header=20 containing the CDO will be encapsulated in other=20 IP headers. So ConEx functions will just have to=20 live with that. To find CDO, they will have to=20 look for an IP header that encapsulates an upper=20 layer protocol header. And even then, they will=20 have to look one level deeper in case IP headers=20 start again. There's loads of kit these days that=20 has to do that anyway (e.g. CGNATs looking for=20 the transport header or DPI looking for the=20 app-layer). This is all we can hope to do at this experimental stage. We need to prove ConEx is useful, then it can be=20 performance optimised. Header parsing performance=20 is generally not a big problem these days. >>>>>* Suggested optional copying of CDO to outer, but also a simpler 'Do >>>>>not copy CDO' alternative. >>>>I don't really get you SHOULD NOT but MAY here...? >>> >>>See earlier. Tunnels don't normally understand dest opts, which is why I >>>said SHOULD NOT. But the MAY is a performance optimisation. Am I helping? >Okay, understood. But why SHOULD NOT? Isn't it=20 >sufficient to say MAY...? (or even MUST/SHOULD if ConEx-aware...?) You're right, we could leave out the SHOULD NOT. I suggest: "As with any destination option, an ingress=20 tunnel endpoint will not natively copy the CDO=20 when adding an encapsulating outer IP header. However, it MAY..." Bob >Mirja > > >>>>>=3D=3DSecurity Considerations=3D=3D >>>>> >>>>>* Added lots, all pointers to where security issues are discussed in >>>>>other places (which is what security directorate reviewers need). >>>>Okay I can add that if you think it's necessary (I would say it's just >>>>redundant, but you be might right that it just helps the sec dir). >>> >>>It's not always obvious which aspects relate to security. Especially >>>when the security is structural rather than crypto. So I think these >>>sentences are useful to sec dir. >>> >>> >>>>>=3D=3DIANA=3D=3D >>>>> >>>>>* I think the act bits need to be 00 not 10 to avoid ConEx packets >>>>>being dropped by non-ConEx nodes (including by non-ConEx receivers)? >>>>>But I'm willing to be corrected. >>>>I agree; Will ask Suresh why he has put a 10 though. >>> >>>Yes, he's the right guy to check with. >>> >>> >>>Bob >>> >>> >>>>Thanks, >>>>Mirja >>>> >>>>> >>>>> >>>>>Regards >>>>> >>>>> >>>>> >>>>> >>>>>Bob >>> >>>{Note 1} >>>For anyone watching on the list, the tentative idea that Mirja has >>>reminded me of is documented in 11.3.1 of my PhD thesis entitled "Covert >>>Markings as a Policer Signal". >>> >>>The potential problem: A ConEx policer punishes punishment. If a >>>congestion policer starts dropping packets because the user has >>>contributed excessively to congestion, in subsequent rounds the user has >>>to re-echo 'L' markings for the policer drops as well. This can drive >>>the policer further into 'debit'. This might make it difficult for the >>>user to get out of trouble once she's started getting into trouble. >>> >>>The basic idea was that when a congestion policer drops packets (because >>>the user is causing more congestion than her allowance), it will also >>>remove ConEx markings. Then (if there is some way for the receiver to >>>feed this back), the sender knows not to send more ConEx marks because >>>these aren't congestion drops, they are policer drops. >>> >>>We didn't that double punishment made it hard to get out of trouble in >>>any policer experiments so far, so let's not allow for a possible >>>solution to a problem that we probably don't even have. The current crop >>>of ConEx drafts are experimental anyway. If this problem does surface, >>>then we can reconsider. >>> >>> >>> >>> >>> >>>________________________________________________________________ >>>Bob Briscoe, BT > >-- >------------------------------------------ >Dipl.-Ing. Mirja K=FChlewind >Communication Systems Group >Institute TIK, ETH Z=FCrich >Gloriastrasse 35, 8092 Z=FCrich, Switzerland > >Room ETZ G93 >phone: +41 44 63 26932 >email: mirja.kuehlewind@tik.ee.ethz.ch >------------------------------------------ ________________________________________________________________ Bob Briscoe, BT=20 From nobody Mon Aug 25 10:36:35 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 06DE31A014A for ; Mon, 25 Aug 2014 10:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, T_TVD_FUZZY_SECURITIES=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 jGcvTZsiJYLU for ; Mon, 25 Aug 2014 10:36:29 -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 6E5BE1A00D6 for ; Mon, 25 Aug 2014 10:36:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3706AD930A; Mon, 25 Aug 2014 19:36:27 +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 KdqEEAZJJo2D; Mon, 25 Aug 2014 19:36:27 +0200 (MEST) 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 E823AD9303; Mon, 25 Aug 2014 19:36:26 +0200 (MEST) Message-ID: <53FB741A.9010500@tik.ee.ethz.ch> Date: Mon, 25 Aug 2014 19:36:26 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch> <53ECE917.6000803@tik.ee.ethz.ch> <201408141915.s7EJFVI8000808@bagheera.jungle.bt.co.uk> In-Reply-To: <201408141915.s7EJFVI8000808@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/4bQMM7AgYh4GLRm8ep2YJxcpvns Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 25 Aug 2014 17:36:34 -0000 On 14.08.2014 21:15, Bob Briscoe wrote: > Mirja, > > At 17:51 14/08/2014, Mirja Kühlewind wrote: >> Hi again, >> >> sorry; pressed sent without being done... see further below.... >> >> On 14.08.2014 18:41, Mirja Kühlewind wrote: >>> Hi Bob, >>> >>> see inline >>> >>>>>> * Added subsection of intro on experiment goals: criteria for success >>>>>> and duration >>>>> >>>>> I believe most of the text actually should go in the tcp mods draft. I >>>>> not sure if there is a common sense in the mean time to have such a >>>>> section in very exp document. But if not I would rather not have it in >>>>> this document because I'm not sure how to define if an experiment was >>>>> successful. If fact the CDO is the only approach at could fulfill our >>>>> requirements, so there is no other option. And if the coding itself >>>>> with the four bits is useful or not, is not really a question of this >>>>> document, but amybe more of the whole mechanism (incl. auditing and >>>>> policing) or maybe the tcp mods document...? >>>> >>>> The solution to this would be to refer to one doc that has the expt >>>> goals. However, I believe each doc can be seen as a separate piece of a >>>> bigger expt. >>>> * The expt that this doc describes is a choice of encoding (see below - >>>> there are other choices). >>>> * The main expt that the TCP doc describes is how to set credit. >>> So is it okay if I just add one sentence in the intro (instead of having >>> an own section): >>> >>> "This specification is experimental to allow the IETF to assess whether >>> the decision to implement the ConEx signal as a destination option >>> fulfills the requirements stated in this document, as well as to >>> evaluate the proposed encoding of the ConEx signals." >>> >>> Does this work for you? > > Why resist the good practice of defining full criteria for success and > duration of experiment? This doc (not TCP) is the primary basis of any > ConEx experiment. I don't mind if it's not in a separate section, but > these elements should be in an expt RFC. > > I think "requirements in abstract-mech" would be more objective. > > I would like it recorded somewhere that it is going to take many > years to find a scenario where a v6-only experiment in traffic > management (on a tiny %age of the traffic) makes any sense whatsoever. > It will be near-impossible to measure whether there is any benefit. > Okay added one more paragraph in the intro based on our initial proposal: "The duration of this experiment is expected to be no less than two years from publication of this document as infrastructure is needed to be set up to determine the outcome of this experiment. Given ConEx is only chartered for IPv6, it might take longer to find a suitable test scenario where only IPv6 traffic is managed using ConEx." Okay? > >>>>>> ==Requirements== >>>>>> >>>>>> * Referred to abstract-mech for requirements, explained that it would >>>>>> be hard to satisfy them all, and explained which one wasn't satisfied >>>>>> (visibility in outer), referring to section on fast-path performance. >>>>> >>>>> Took over some of your text at the beginning of this section (and also >>>>> reused some text we already used to have there). >>>>> >>>>> Do you really think that the two requirements you've added are needed? >>>>> Because both basically say that the ConEx coding should encode the >>>>> Conex signal, which is, from my point of view, the whole purpose of >>>>> this document. >>>> >>>> Perhaps you're too close to ConEx. If these reqs hadn't been defined in >>>> abstract-mech, you wouldn't know what "the ConEx signal" was. These >>>> reqs >>>> say what the component parts of the ConEx signal are. It could say you >>>> need separate signals for ECN-credit and loss-credit. It could say >>>> ConEx >>>> nodes must successfully negotiate ECN (then re-ECN would be a >>>> solution). >>>> >>>> The alternative is to refer to abstract-mech for all the requirements >>>> and not list them here, or list the reqs in abstract-mech that are >>>> relevant to the network layer encoding. >>>> >>>>> I do have the feeling that the other requirements listed here are on a >>>>> slightly different level because they are more related to deployment >>>>> issues. >>>> >>>> You could say that (but you don't). That's why it seemed odd that you >>>> listed some requirements, but not the basic ones. >>> Okay the intent of these requirements was not to rephrase what is >>> already written down in the abstract-mech because I assume that people >>> reading this document do not really care why the conex signals look as >>> they do but just want to know which conex signals are there (and what >>> there meaning is). >>> The reason to have the requirement listed is simply to justify the >>> potentially awkward choice to encode them in a destination option. >>> >>> I now have the following text: >>> >>> "A set of requirement for an ideal concrete ConEx wire protocol is given >>> in . In the ConEx working >>> group is was recognized that it will be difficult to find an encoding in >>> IPv6 that satisfies all requirements. The choice in this document to >>> implement the ConEx information in a destination option satisfies most >>> of those requirements, briefly summarized below:" >>> >>> + I added your paragraph on visibility at the end. >>> >>> Okay? > > How about not including the 2 extra requirements and changing your last > sentence now I understand what you want to say: > > "The choice in this document to implement the ConEx information in a > destination option aims to satisfy those requirements that constrain the > placement of ConEx information:" > Done. > > >>>>> And regarding tunneling: you are right that we need to give more >>>>> advise on tunneling. Shouldn't we just say that one MUST copy the >>>>> inner ConEx Option to the outer header (to solve the visibility >>>>> problem)? >>>> >>>> You can't say MUST, because IPv6 dest opts are meant to be e2e only, so >>>> no IPv6 tunnel currently even understands what a dest opt is, let alone >>>> copies any dest opt to the outer. A MUST would ring huge alarm bells in >>>> the vendor community. >>>> >>>> I added it as a MAY, purely because it might be considered a >>>> performance >>>> optimisation. I'm still worried about the size of the alarm bells that >>>> will ring. It could prevent this draft progressing thru the IESG. >>>> Suresh >>>> will know best how this might be received in the IESG. >>> Okay, got it; see further below... >>> >>>> >>>> >>>>>> ==CDO== >>>>> >>>>>> * Specified precisely which IP header is included in the byte count. >>>>> So you suggest to not include any options? >>>> >>>> I didn't say that, did I? If the wording I used is ambiguous, pls >>>> fix it. >>>> >>>>> Why? I'd say you either include all bits because all of them >>>>> contribute to congestion, or none of the IP header bits because that's >>>>> just the overhead you can't avoid if you what to send anything. Also >>>>> of course you can generate a larger percentage of overhead if you send >>>>> smaller packets. >>>> >>>> That's why I think it is reasonable to include the IP header (and its >>>> options) that immediately encapsulates the ConEx dest opt. >>> Okay I misread your text. >>> >>> I just though, if you detect a CDO in the header you are currently >>> looking at, you will simply look at the playload length and next hop >>> fields of this header and than add another 40 bytes for the header >>> itself. But in fact that might be wrong if you have another IP header >>> encapsulated in the payload... so what is actually the right number of >>> bytes here? >>> >>> I was about to write the following but I'm not sure if that is actually >>> write and/or clear: >>> "... IP packet (including the IP header that carries the CDO and all >>> associated options)..."? >>> That just doesn't say if you should look what the next header is and >>> subtract all other IP header bytes you can find. Is this needed? > > I'm happy with your something like your last sentence. For precision I > suggest rewording: > > IP packet (including the IP header that directly encapsulates the CDO > and everything that IP header encapsulates). Done > > It doesn't have to go searching for any more deeply encapsulated CDO. If > there is one, that will be dealt with by whatever higher layer it was > written in, at the point when the outer layers have been peeled off and > some function at that higher layer is processing these inner dest opts. My point actually was that you will get a different number of marked bytes if you look at a point with or without encapsulation. But as usually all packets (at least of the same flow) get encapsulated or not, the ratio between marked and not-marked bytes should still be the same, so I guess that's fine. > > > > >>>>>> * Suggested deleting example of Not-ConEx-capable packets (see >>>>>> separate thread to conex-tcp-modifications authors about TCP pure >>>>>> ACKs). >>>>> I can remove the example but not sure why you are suggesting this. If >>>>> you actually imply that the X bit should never be zero that we have to >>>>> discuss if the X bit is needed at all. >>>> >>>> I have never thought the X flag was needed. There's probably some email >>>> on the list somewhere in the past from me that says that. >>>> >>>> As I put in one of the comment bubbles: >>>> "The only need I can see for the X-flag is if >>>> the Reserved field gets used in future for >>>> something in addition to ConEx. Then there >>>> would be a need to identify packets that >>>> are not ConEx-capable but still carry the >>>> CDO option (for the new reason)." >>>> >>>> Can anyone think of a use for the X flag? >>> I thought the X bit unset means: I'm a ConEx aware sender and i want to >>> follow the rules but I don't have any feedback for this (control) data >>> so I'm unable to give you useful ConEx information and if you use this >>> packet for your estimation of the current congestion level, you might >>> underestimate it. >>> >>> Doesn't that make sense...? > > Not to me. What does "feedback for this (control) data" mean? Feedback > is about a path used by a 5-tuple. This control data is about to be sent > over such a path. If the sender has feedback about that path, the > feedback applies to everything sent over the path, at the IP layer, > whatever categorisation the next packet has at L4. If you do not get any feedback on a path, e.g. a receiver only sending ACKs, you will never be able to send any ConEx markings. So what's the point about marking a packet as ConEx-enabled? Further note, in the TCP mods we only look at the payload because we assume, for simplification, all packets have the same size. Therefore a packet that carries no data would not decrease the CEG/LEG. If ACKs should get marked, we need to rewrite all this stuff in the tcp mods doc... > (Even if control data is somehow being sent over a different path, e.g. > using MPTCP or something, and there has never been feedback over that > path, then that would warrant Credit, not absence of ConEx.) I don't think credit does help here. Note credit cannot replace ConEx-markings anymore. And if you only send a small amount of control data, it is not very likely that your packets gets drop and thus probably you do not sent any credit. > > > >>>>>> ==Fast-path== >>>>>> >>>>>> * CDO as first destination option: changed from MUST to SHOULD (with >>>>>> an example of when not to). >>>>> I believe this really needs to be a MUST. I know that might restrict >>>>> the use of ConEx with potential other options that might have the same >>>>> requirement (for different reasons). But if you don't put a MUST here, >>>>> you cannot implemented the suggested way in the fast path. >>>> >>>> A SHOULD still means it will be the first option in all current >>>> implementations. However, I suggest a SHOULD, precisely because >>>> performance reasons are not absolute, so they don't require a MUST. If >>>> another dest opt cannot work at all unless it is first, that would be a >>>> valid reason for CDO coming second, because it still works, it's /just/ >>>> slower. >>>> >>>> The IESG will (rightly) be very wary of any draft that says an option >>>> MUST be the first option. >>>> >>>> I suggested the following text after this: "(This is not >>>> stated as a 'MUST', because some future destination option might >>>> need to >>>> be placed first for functional rather than just performance reasons.)" >>> So our fast path implementation must simply assume that there is no CDO >>> in case it cannot find it as the first option. Otherwise all non-ConEx >>> packets would need to go to the slow path to make sure there is no ConEx >>> option. That means to me that this must be a MUST...? > > OK, I see the problem, but how much of a performance problem would it > really be for the fast path of a ConEx function to step along dest opts > until it gets to CDO then stops (rather than stop if CDO is not first)? So that's the different between you looking at one bit at a defined position or having a chain of conditional look-ups where the length is unknown. I believe that is something you would avoid to implement in fast path as the processing time is not fixed anymore... that would be my guess but I'm not an expert in this area. > > Then "CDO SHOULD be first" would give no different performance to "CDO > MUST be first", if CDO actually was first. If CDO had to be placed > second on a certain packet, "CDO SHOULD be first" would take just one > more op than "CDO MUST be first". > > Note: I've just re-read the spec of the IPv6 header. We need to specify > that CDO goes in the "Destination Options (before routing header)", not > the "Destination Options (before upper-layer header)". Then it won't be > encrypted by an ESP header. Thanks. I wasn't fully aware of this. But the difference for my understanding is if immediate node listed in the routing header should proceed this option or not. In our case it is probably not important which one we choose as it should be processed by none of the receivers. Where did you read that the later one is not encrypted though? If so, I can simply add one sentence to the first paragraph of section 4: "The CDO MUST be placed in the destination option before routing header such that it does not get encrypted and can be read by immediate ConEx-aware nodes." And then remove the first paragraph of the IPSec section (and probably move the other paragraph somewhere else so that the section is removed completely)...? > > > >>>>>> ==IPsec compatibility== >>>>>> >>>>>> * Suggested ConEx counts the AH header, and the outer tunnel mode >>>>>> header, with reasoning. >>>>> Yes, need to be more precise. Will add. >>>> >>>> This one wasn't just clarity. I've actually contradicted what was said, >>>> so pls make sure there wasn't a good reason for why it was like it was. >>>> >>>> I was most concerned about suggesting this change, because it was the >>>> only one that caused a technical difference. >>> Ohh, I didn't read your comments carefully and was just looking at the >>> text changes... this whole accounting is a mess :-( > > I don't think it has to be, if we keep to the rule we just agreed above. > >>> Maybe we should only account the IPv6 header itself and the destination >>> options...? > > Why? I really don't understand why the IPsec accounting was written like > it was. Pls explain. The problem about tunneling is that the number of ConEx marked bytes might be different depending on where at the path you look at the packets. But I guess that's less a problem than I initially though. If so I guess I can remove this paragraph about accounting in the IPSec section (if still needed at all). > > >>> Moreover, isn't this here the same case than with tunneling in general. >>> Only if the node that does the encapsulation is ConEx-aware it can copy >>> the CDO, otherwise it will be not visible anymore. >>> >>> So this should either be a should, or we have to say something like: if >>> the node is ConEx-aware is MUST copy the CDO...? >> And then we can the same thing for tunneling in general...? > > That's surely a circular argument. What would make a tunnel endpoint > into a ConEx-aware tunnel endpoint, so that it would have to copy the > CDO? It would only become ConEx-aware if it had code added to look for > the CDO, and why would it have that code added unless it was going to do > something with CDO? That's why I think my 'MAY copy as a performance > optimisation' formula is the best we can do. What you say above is the point. If the node does not know anything about ConEx, it simple cannot copy the option, which is the case for all currently existent nodes. So we cannot say MUST in general. But if the node does know that ConEx exists for any reason, it really must copy the CDO...? But you right that is a little pathologic. I'm will to change if that helps understanding/is less confusing. > > There is no point trying to fix the IPv6 facilities for tunnelling new > extension headers. The people whose job it was to design this didn't do > their job. Their design is now burned into IPv6 hardware processors > everywhere. Full stop. > > All we can hope to do is ensure that CDO is not encrypted with ESP. That > is feasible. > > Whatever we do, in many cases, the IPv6 header containing the CDO will > be encapsulated in other IP headers. So ConEx functions will just have > to live with that. To find CDO, they will have to look for an IP header > that encapsulates an upper layer protocol header. And even then, they > will have to look one level deeper in case IP headers start again. > There's loads of kit these days that has to do that anyway (e.g. CGNATs > looking for the transport header or DPI looking for the app-layer). This > is all we can hope to do at this experimental stage. I guess we should write this point more explicitly: "A network node that assesses ConEx information SHOULD search for encapsulated IP headers until a CDO is found or no further IP headers can be found." (should or SHOULD?) > > We need to prove ConEx is useful, then it can be performance optimised. > Header parsing performance is generally not a big problem these days. > > >>>>>> * Suggested optional copying of CDO to outer, but also a simpler 'Do >>>>>> not copy CDO' alternative. >>>>> I don't really get you SHOULD NOT but MAY here...? >>>> >>>> See earlier. Tunnels don't normally understand dest opts, which is >>>> why I >>>> said SHOULD NOT. But the MAY is a performance optimisation. Am I >>>> helping? >> Okay, understood. But why SHOULD NOT? Isn't it sufficient to say >> MAY...? (or even MUST/SHOULD if ConEx-aware...?) > > You're right, we could leave out the SHOULD NOT. I suggest: > > "As with any destination option, an ingress tunnel endpoint will not > natively copy the CDO when adding an encapsulating outer IP header. > However, it MAY..." Done. But one question: Why MAY and not SHOULD? Wouldn't it actually be nice if all future tunneling nodes would copy the header. > > > > > Bob > > >> Mirja >> >> >>>>>> ==Security Considerations== >>>>>> >>>>>> * Added lots, all pointers to where security issues are discussed in >>>>>> other places (which is what security directorate reviewers need). >>>>> Okay I can add that if you think it's necessary (I would say it's just >>>>> redundant, but you be might right that it just helps the sec dir). >>>> >>>> It's not always obvious which aspects relate to security. Especially >>>> when the security is structural rather than crypto. So I think these >>>> sentences are useful to sec dir. >>>> >>>> >>>>>> ==IANA== >>>>>> >>>>>> * I think the act bits need to be 00 not 10 to avoid ConEx packets >>>>>> being dropped by non-ConEx nodes (including by non-ConEx receivers)? >>>>>> But I'm willing to be corrected. >>>>> I agree; Will ask Suresh why he has put a 10 though. >>>> >>>> Yes, he's the right guy to check with. >>>> >>>> >>>> Bob >>>> >>>> >>>>> Thanks, >>>>> Mirja >>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Bob >>>> >>>> {Note 1} >>>> For anyone watching on the list, the tentative idea that Mirja has >>>> reminded me of is documented in 11.3.1 of my PhD thesis entitled >>>> "Covert >>>> Markings as a Policer Signal". >>>> >>>> The potential problem: A ConEx policer punishes punishment. If a >>>> congestion policer starts dropping packets because the user has >>>> contributed excessively to congestion, in subsequent rounds the user >>>> has >>>> to re-echo 'L' markings for the policer drops as well. This can drive >>>> the policer further into 'debit'. This might make it difficult for the >>>> user to get out of trouble once she's started getting into trouble. >>>> >>>> The basic idea was that when a congestion policer drops packets >>>> (because >>>> the user is causing more congestion than her allowance), it will also >>>> remove ConEx markings. Then (if there is some way for the receiver to >>>> feed this back), the sender knows not to send more ConEx marks because >>>> these aren't congestion drops, they are policer drops. >>>> >>>> We didn't that double punishment made it hard to get out of trouble in >>>> any policer experiments so far, so let's not allow for a possible >>>> solution to a problem that we probably don't even have. The current >>>> crop >>>> of ConEx drafts are experimental anyway. If this problem does surface, >>>> then we can reconsider. >>>> >>>> >>>> >>>> >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, BT >> >> -- >> ------------------------------------------ >> 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 >> ------------------------------------------ > > ________________________________________________________________ > Bob Briscoe, BT > -- ------------------------------------------ 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 Aug 26 10:28:05 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 CBDF11A001E for ; Tue, 26 Aug 2014 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=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 bMRnlxDfNJpC for ; Tue, 26 Aug 2014 10:27:54 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEB31A0062 for ; Tue, 26 Aug 2014 10:27:53 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 26 Aug 2014 18:27:49 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 26 Aug 2014 18:27:51 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 26 Aug 2014 18:27:51 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.142]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7QHRlxB026767; Tue, 26 Aug 2014 18:27:48 +0100 Message-ID: <201408261727.s7QHRlxB026767@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Aug 2014 18:27:45 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <53FB741A.9010500@tik.ee.ethz.ch> References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch> <53ECE917.6000803@tik.ee.ethz.ch> <201408141915.s7EJFVI8000808@bagheera.jungle.bt.co.uk> <53FB741A.9010500@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/afVRgDMHf2B3XUKlUc8y1eYxBTE Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 26 Aug 2014 17:28:00 -0000 Mirja, Inline. [I've re-added Suresh who seems to have got lost=20 from the distr - he's a good person to double check what we've decided.] At 18:36 25/08/2014, Mirja K=FChlewind wrote: >On 14.08.2014 21:15, Bob Briscoe wrote: >>Mirja, >> >>At 17:51 14/08/2014, Mirja K=FChlewind wrote: >>>Hi again, >>> >>>sorry; pressed sent without being done... see further below.... >>> >>>On 14.08.2014 18:41, Mirja K=FChlewind wrote: >>>>Hi Bob, >>>> >>>>see inline >>>> >>>>>>>* Added subsection of intro on experiment goals: criteria for success >>>>>>>and duration >>>>>> >>>>>>I believe most of the text actually should go in the tcp mods draft. I >>>>>>not sure if there is a common sense in the mean time to have such a >>>>>>section in very exp document. But if not I would rather not have it in >>>>>>this document because I'm not sure how to define if an experiment was >>>>>>successful. If fact the CDO is the only approach at could fulfill our >>>>>>requirements, so there is no other option. And if the coding itself >>>>>>with the four bits is useful or not, is not really a question of this >>>>>>document, but amybe more of the whole mechanism (incl. auditing and >>>>>>policing) or maybe the tcp mods document...? >>>>> >>>>>The solution to this would be to refer to one doc that has the expt >>>>>goals. However, I believe each doc can be seen as a separate piece of a >>>>>bigger expt. >>>>>* The expt that this doc describes is a choice of encoding (see below - >>>>>there are other choices). >>>>>* The main expt that the TCP doc describes is how to set credit. >>>>So is it okay if I just add one sentence in the intro (instead of having >>>>an own section): >>>> >>>>"This specification is experimental to allow the IETF to assess whether >>>>the decision to implement the ConEx signal as a destination option >>>>fulfills the requirements stated in this document, as well as to >>>>evaluate the proposed encoding of the ConEx signals." >>>> >>>>Does this work for you? >> >>Why resist the good practice of defining full criteria for success and >>duration of experiment? This doc (not TCP) is the primary basis of any >>ConEx experiment. I don't mind if it's not in a separate section, but >>these elements should be in an expt RFC. >> >>I think "requirements in abstract-mech" would be more objective. >> >>I would like it recorded somewhere that it is going to take many >>years to find a scenario where a v6-only experiment in traffic >>management (on a tiny %age of the traffic) makes any sense whatsoever. >>It will be near-impossible to measure whether there is any benefit. >> > >Okay added one more paragraph in the intro based on our initial proposal: >"The duration of this experiment is expected to=20 >be no less than two years from publication of=20 >this document as infrastructure is needed to be=20 >set up to determine the outcome of this=20 >experiment. Given ConEx is only chartered for=20 >IPv6, it might take longer to find a suitable=20 >test scenario where only IPv6 traffic is managed using ConEx." >Okay? Yup. Thx. BTW, a para (or section) about experiment goals=20 doesn't have to be in the Intro. If you'd prefer=20 to keep the intro focused, this could be near the end of the doc. >>>>>>>=3D=3DRequirements=3D=3D >>>>>>> >>>>>>>* Referred to abstract-mech for requirements, explained that it would >>>>>>>be hard to satisfy them all, and explained which one wasn't satisfied >>>>>>>(visibility in outer), referring to section on fast-path performance. >>>>>> >>>>>>Took over some of your text at the beginning of this section (and also >>>>>>reused some text we already used to have there). >>>>>> >>>>>>Do you really think that the two requirements you've added are needed? >>>>>>Because both basically say that the ConEx coding should encode the >>>>>>Conex signal, which is, from my point of view, the whole purpose of >>>>>>this document. >>>>> >>>>>Perhaps you're too close to ConEx. If these reqs hadn't been defined in >>>>>abstract-mech, you wouldn't know what "the ConEx signal" was. These >>>>>reqs >>>>>say what the component parts of the ConEx signal are. It could say you >>>>>need separate signals for ECN-credit and loss-credit. It could say >>>>>ConEx >>>>>nodes must successfully negotiate ECN (then re-ECN would be a >>>>>solution). >>>>> >>>>>The alternative is to refer to abstract-mech for all the requirements >>>>>and not list them here, or list the reqs in abstract-mech that are >>>>>relevant to the network layer encoding. >>>>> >>>>>>I do have the feeling that the other requirements listed here are on a >>>>>>slightly different level because they are more related to deployment >>>>>>issues. >>>>> >>>>>You could say that (but you don't). That's why it seemed odd that you >>>>>listed some requirements, but not the basic ones. >>>>Okay the intent of these requirements was not to rephrase what is >>>>already written down in the abstract-mech because I assume that people >>>>reading this document do not really care why the conex signals look as >>>>they do but just want to know which conex signals are there (and what >>>>there meaning is). >>>>The reason to have the requirement listed is simply to justify the >>>>potentially awkward choice to encode them in a destination option. >>>> >>>>I now have the following text: >>>> >>>>"A set of requirement for an ideal concrete ConEx wire protocol is given >>>>in . In the ConEx working >>>>group is was recognized that it will be difficult to find an encoding in >>>>IPv6 that satisfies all requirements. The choice in this document to >>>>implement the ConEx information in a destination option satisfies most >>>>of those requirements, briefly summarized below:" >>>> >>>>+ I added your paragraph on visibility at the end. >>>> >>>>Okay? >> >>How about not including the 2 extra requirements and changing your last >>sentence now I understand what you want to say: >> >>"The choice in this document to implement the ConEx information in a >>destination option aims to satisfy those requirements that constrain the >>placement of ConEx information:" >Done. > >> >> >>>>>>And regarding tunneling: you are right that we need to give more >>>>>>advise on tunneling. Shouldn't we just say that one MUST copy the >>>>>>inner ConEx Option to the outer header (to solve the visibility >>>>>>problem)? >>>>> >>>>>You can't say MUST, because IPv6 dest opts are meant to be e2e only, so >>>>>no IPv6 tunnel currently even understands what a dest opt is, let alone >>>>>copies any dest opt to the outer. A MUST would ring huge alarm bells in >>>>>the vendor community. >>>>> >>>>>I added it as a MAY, purely because it might be considered a >>>>>performance >>>>>optimisation. I'm still worried about the size of the alarm bells that >>>>>will ring. It could prevent this draft progressing thru the IESG. >>>>>Suresh >>>>>will know best how this might be received in the IESG. >>>>Okay, got it; see further below... >>>> >>>>> >>>>> >>>>>>>=3D=3DCDO=3D=3D >>>>>> >>>>>>>* Specified precisely which IP header is included in the byte count. >>>>>>So you suggest to not include any options? >>>>> >>>>>I didn't say that, did I? If the wording I used is ambiguous, pls >>>>>fix it. >>>>> >>>>>>Why? I'd say you either include all bits because all of them >>>>>>contribute to congestion, or none of the IP header bits because that's >>>>>>just the overhead you can't avoid if you what to send anything. Also >>>>>>of course you can generate a larger percentage of overhead if you send >>>>>>smaller packets. >>>>> >>>>>That's why I think it is reasonable to include the IP header (and its >>>>>options) that immediately encapsulates the ConEx dest opt. >>>>Okay I misread your text. >>>> >>>>I just though, if you detect a CDO in the header you are currently >>>>looking at, you will simply look at the playload length and next hop >>>>fields of this header and than add another 40 bytes for the header >>>>itself. But in fact that might be wrong if you have another IP header >>>>encapsulated in the payload... so what is actually the right number of >>>>bytes here? >>>> >>>>I was about to write the following but I'm not sure if that is actually >>>>write and/or clear: >>>>"... IP packet (including the IP header that carries the CDO and all >>>>associated options)..."? >>>>That just doesn't say if you should look what the next header is and >>>>subtract all other IP header bytes you can find. Is this needed? >> >>I'm happy with your something like your last sentence. For precision I >>suggest rewording: >> >>IP packet (including the IP header that directly encapsulates the CDO >>and everything that IP header encapsulates). >Done > >> >>It doesn't have to go searching for any more deeply encapsulated CDO. If >>there is one, that will be dealt with by whatever higher layer it was >>written in, at the point when the outer layers have been peeled off and >>some function at that higher layer is processing these inner dest opts. >My point actually was that you will get a=20 >different number of marked bytes if you look at=20 >a point with or without encapsulation. But as=20 >usually all packets (at least of the same flow)=20 >get encapsulated or not, the ratio between=20 >marked and not-marked bytes should still be the same, so I guess that's= fine. Yup. When relative proportions are used, there's not a problem. Even where absolute packet size matters (e.g. a=20 congestion policer or more generally a policy=20 device configured with a certain rate of=20 congestion allowance), the proposed definition can work,... as follows There are two possibilities where there might be=20 a more deeply encapsulated CDO: i) Two independent systems are initiating=20 different congestion feedback loops, and they are=20 both reinserting ConEx markings. ii) The inner CDO has at some point been copied to the outer I was talking about case (i) before, where the=20 sender and all policy devices are working at=20 their own layer on their own control loop,=20 unaware of another ConEx control loop at another layer (which is fine). Case (ii) could lead to a bias in the amount of=20 congestion counted. This is why I suggested that=20 the only time a tunnel endpoint copies CDO to the=20 outer is as a performance optimisation. E.g.=20 where an operator is tunnelling packets across=20 its own network and it knows there are ConEx=20 policy devices within its own network, so it=20 saves them the hassle of burying into the tunnel. So case (ii) is also fine, as long as the=20 operator doing the optimisation is aware of both=20 its tunnels and its policy devices, and=20 configures the policy device to make the=20 (constant) allowance for the additional tunnel headers. Perhaps we need to add text where we suggest this=20 optimisation to say that the operator should=20 ensure all packets are decapsulated back how they=20 were before passing on to another operator that=20 is not aware of the optimisation. But, this is getting over-detailed... >>>>>>>* Suggested deleting example of Not-ConEx-capable packets (see >>>>>>>separate thread to conex-tcp-modifications authors about TCP pure >>>>>>>ACKs). >>>>>>I can remove the example but not sure why you are suggesting this. If >>>>>>you actually imply that the X bit should never be zero that we have to >>>>>>discuss if the X bit is needed at all. >>>>> >>>>>I have never thought the X flag was needed. There's probably some email >>>>>on the list somewhere in the past from me that says that. >>>>> >>>>>As I put in one of the comment bubbles: >>>>>"The only need I can see for the X-flag is if >>>>>the Reserved field gets used in future for >>>>>something in addition to ConEx. Then there >>>>>would be a need to identify packets that >>>>>are not ConEx-capable but still carry the >>>>>CDO option (for the new reason)." >>>>> >>>>>Can anyone think of a use for the X flag? >>>>I thought the X bit unset means: I'm a ConEx aware sender and i want to >>>>follow the rules but I don't have any feedback for this (control) data >>>>so I'm unable to give you useful ConEx information and if you use this >>>>packet for your estimation of the current congestion level, you might >>>>underestimate it. >>>> >>>>Doesn't that make sense...? >> >>Not to me. What does "feedback for this (control) data" mean? Feedback >>is about a path used by a 5-tuple. This control data is about to be sent >>over such a path. If the sender has feedback about that path, the >>feedback applies to everything sent over the path, at the IP layer, >>whatever categorisation the next packet has at L4. >If you do not get any feedback on a path, e.g. a=20 >receiver only sending ACKs, you will never be=20 >able to send any ConEx markings. So what's the=20 >point about marking a packet as ConEx-enabled? OK, this is a good example for when a=20 ConEx-enabled flag might be useful. However,... ...This doesn't justify marking pure ACKs as=20 not-ConEx-enabled. If a sender sends a pure ACK=20 now, all it knows is that it might not have=20 enough feedback to be able to set ConEx markings=20 on a whole sequence of packets later in the=20 flow,... but only if it keeps sending solely pure=20 ACKs from now on. However, a sender can't be sure=20 that it won't have enough feedback in future,=20 because usually an app (let alone the transport=20 layer) cannot predict whether there will be more=20 data to send later, even if it's not sending any now. Once a sender has had no feedback for at least a=20 round trip, it has 2 options for subsequent packets: a) turn off ConEx-enabled; b) keep sending packets with ConEx-enabled set,=20 but conservatively add some credit. Even if it subsequently sends some data, it will=20 still have to do (a) or (b) on these data=20 packets, at least for one further round trip,=20 until it gets the feedback. So this is nothing to=20 do with whether the packet being sent is a pure=20 ACK. It is to do with whether feedback has recently been received. >Further note, in the TCP mods we only look at=20 >the payload because we assume, for=20 >simplification, all packets have the same size.=20 >Therefore a packet that carries no data would=20 >not decrease the CEG/LEG. If ACKs should get=20 >marked, we need to rewrite all this stuff in the tcp mods doc... I don't think we should avoid changing tcp-mods if its 'not right'. I hope you see the problem from my explanation=20 above - whether there is enough feedback /now/ to=20 ConEx-mark a packet has nothing to do with=20 whether the packet being sent /now/ is capable of=20 generating feedback /in the next round/. If you want to make a simplifying assumption, it=20 is on the safe side for a sender to assume that=20 all incoming feedback is about packets of the=20 same size. It's not safe for a sender to assume=20 that all packets it is sending are the same size.=20 Anyway, it knows what size it is sending, so it=20 doesn't need this simplification. The simplification I propose (that feedback is=20 all about the same size packets, rather than all=20 the sent packets are the same size) is likely to=20 be pretty good, given the receiver doesn't get=20 loss or ECN info about pure ACKs, so they are=20 automatically removed from the set of packets=20 that the sender assumes to be the same size. And,=20 and if some of the feedback is about smaller data=20 packets, at least this simplification will always be on the safe side. If I correctly understand the simplification you=20 propose, a ConEx sender will more often=20 under-declare congestion than over-declaring, which is not safe. >>(Even if control data is somehow being sent over a different path, e.g. >>using MPTCP or something, and there has never been feedback over that >>path, then that would warrant Credit, not absence of ConEx.) >I don't think credit does help here. Note credit=20 >cannot replace ConEx-markings anymore. OK, I should have said "then that would warrant=20 conservatively sending some credit and corresponding L or E markings." A sender can always send more ConEx marks than=20 actual congestion, and if it doesn't know actual=20 congestion, it can at least hold an initial=20 estimate of what worst-case congestion might be (e.g. 1%). However, I admit that, if it only sends pure ACKs=20 and this estimate is too low, it will never know=20 it is too low, and the audit function might be=20 dropping loads of its pure ACKs. Ug. This is a=20 new issue I hadn't thought of before... so I=20 think we should recommend option a), not b). > And if you only send a small amount of control=20 > data, it is not very likely that your packets=20 > gets drop and thus probably you do not sent any credit. That's reasonable. >>>>>>>=3D=3DFast-path=3D=3D >>>>>>> >>>>>>>* CDO as first destination option: changed from MUST to SHOULD (with >>>>>>>an example of when not to). >>>>>>I believe this really needs to be a MUST. I know that might restrict >>>>>>the use of ConEx with potential other options that might have the same >>>>>>requirement (for different reasons). But if you don't put a MUST here, >>>>>>you cannot implemented the suggested way in the fast path. >>>>> >>>>>A SHOULD still means it will be the first option in all current >>>>>implementations. However, I suggest a SHOULD, precisely because >>>>>performance reasons are not absolute, so they don't require a MUST. If >>>>>another dest opt cannot work at all unless it is first, that would be a >>>>>valid reason for CDO coming second, because it still works, it's /just/ >>>>>slower. >>>>> >>>>>The IESG will (rightly) be very wary of any draft that says an option >>>>>MUST be the first option. >>>>> >>>>>I suggested the following text after this: "(This is not >>>>>stated as a 'MUST', because some future destination option might >>>>>need to >>>>>be placed first for functional rather than just performance reasons.)" >>>>So our fast path implementation must simply assume that there is no CDO >>>>in case it cannot find it as the first option. Otherwise all non-ConEx >>>>packets would need to go to the slow path to make sure there is no ConEx >>>>option. That means to me that this must be a MUST...? >> >>OK, I see the problem, but how much of a performance problem would it >>really be for the fast path of a ConEx function to step along dest opts >>until it gets to CDO then stops (rather than stop if CDO is not first)? >So that's the different between you looking at=20 >one bit at a defined position or having a chain=20 >of conditional look-ups where the length is=20 >unknown. I believe that is something you would=20 >avoid to implement in fast path as the=20 >processing time is not fixed anymore... that=20 >would be my guess but I'm not an expert in this area. AFAICT, fast path implementations generally work=20 along sequences of extensions. So I don't think=20 this is a problem. Bear in mind that we are not=20 asking general fast path forwarding=20 implementations to do this. Only ConEx functions=20 specifically written to find the ConEx header.{Note 1} {Note 1} OK, we do suggest that general=20 forwarding functions could do DoS protection=20 using the ConEx header. But that's stated as=20 optional and 'aspirational'. If such an=20 experiment proves useful, you never know, there=20 could be demand for ConEx to migrate into the=20 hop-by-hop options (according to the v6 spec,=20 hop-by-hop and dest options share the same option=20 number space, so this would be a straightforward=20 migration, just moving where the CDO is placed,=20 but using the same option number and format). >>Then "CDO SHOULD be first" would give no different performance to "CDO >>MUST be first", if CDO actually was first. If CDO had to be placed >>second on a certain packet, "CDO SHOULD be first" would take just one >>more op than "CDO MUST be first". >> >>Note: I've just re-read the spec of the IPv6 header. We need to specify >>that CDO goes in the "Destination Options (before routing header)", not >>the "Destination Options (before upper-layer header)". Then it won't be >>encrypted by an ESP header. >Thanks. I wasn't fully aware of this. But the=20 >difference for my understanding is if immediate=20 >node listed in the routing header should proceed=20 >this option or not. In our case it is probably=20 >not important which one we choose as it should=20 >be processed by none of the receivers. You're correct that CDO isn't processed by any of=20 the nodes listed in the routing header as=20 destinations. The phrase "before routing header"=20 is just how its placement is described. We should=20 clarify that this isn't anything to do with the=20 processing of the routing header. >Where did you read that the later one is not encrypted though? ESP encrypts everything after the ESP header, and=20 it comes just before the second dest opts. So it=20 would be no good putting CDO after it. See the ESP spec, on "ESP Header Location": " The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. " Also see the IPv6 spec on "Extension Header Order": I believe one reason there are two places for the=20 dest opt is because if ESP is encrypting=20 everything for the destination, it will normally=20 be expected that the dest opts need to be=20 encrypted too. But this wouldn't work if you have=20 multiple destinations on the path in the routing=20 header (that probably don't hold the relevant=20 key). Fortunately, this exception is also needed for ConEx. >If so, I can simply add one sentence to the first paragraph of section 4: >"The CDO MUST be placed in the destination=20 >option before routing header such that it does=20 >not get encrypted and can be read by immediate ConEx-aware nodes." >And then remove the first paragraph of the IPSec=20 >section (and probably move the other paragraph=20 >somewhere else so that the section is removed completely)...? I've lost track of all the proposed changes to=20 the IPsec section. But I think there is value in=20 spelling out exactly how ConEx and IPsec=20 interact, so I wouldn't remove the section=20 completely, even if it repeats info elsewhere. >>>>>>>=3D=3DIPsec compatibility=3D=3D >>>>>>> >>>>>>>* Suggested ConEx counts the AH header, and the outer tunnel mode >>>>>>>header, with reasoning. >>>>>>Yes, need to be more precise. Will add. >>>>> >>>>>This one wasn't just clarity. I've actually contradicted what was said, >>>>>so pls make sure there wasn't a good reason for why it was like it was. >>>>> >>>>>I was most concerned about suggesting this change, because it was the >>>>>only one that caused a technical difference. >>>>Ohh, I didn't read your comments carefully and was just looking at the >>>>text changes... this whole accounting is a mess :-( >> >>I don't think it has to be, if we keep to the rule we just agreed above. >> >>>>Maybe we should only account the IPv6 header itself and the destination >>>>options...? >> >>Why? I really don't understand why the IPsec accounting was written like >>it was. Pls explain. >The problem about tunneling is that the number=20 >of ConEx marked bytes might be different=20 >depending on where at the path you look at the=20 >packets. But I guess that's less a problem than=20 >I initially though. If so I guess I can remove=20 >this paragraph about accounting in the IPSec section (if still needed at= all). If you're saying that the new definition of what=20 to count removes the problem, because counting is=20 no longer dependent on whether there are encapsulating headers, I agree. >>>>Moreover, isn't this here the same case than with tunneling in general. >>>>Only if the node that does the encapsulation is ConEx-aware it can copy >>>>the CDO, otherwise it will be not visible anymore. >>>> >>>>So this should either be a should, or we have to say something like: if >>>>the node is ConEx-aware is MUST copy the CDO...? >>>And then we can the same thing for tunneling in general...? >> >>That's surely a circular argument. What would make a tunnel endpoint >>into a ConEx-aware tunnel endpoint, so that it would have to copy the >>CDO? It would only become ConEx-aware if it had code added to look for >>the CDO, and why would it have that code added unless it was going to do >>something with CDO? That's why I think my 'MAY copy as a performance >>optimisation' formula is the best we can do. >What you say above is the point. If the node=20 >does not know anything about ConEx, it simple=20 >cannot copy the option, which is the case for=20 >all currently existent nodes. So we cannot say=20 >MUST in general. But if the node does know that=20 >ConEx exists for any reason, it really must copy=20 >the CDO...? But you right that is a little=20 >pathologic. I'm will to change if that helps understanding/is less= confusing. I think we're talking past each other. Given we=20 cannot copy CDO to the outer everywhere, for=20 consistency I don't think that copying CDO to the=20 outer at all is a good idea, UNLESS it's done=20 deliberately as part of an operator's whole=20 approach to handling ConEx. Ie. tunnel endpoints=20 SHOULD NOT copy CDO to the outer by default, but=20 they MAY copy CDO to the outer for a specific=20 purpose (e.g. optimisation for ConEx functions=20 elsewhere in the same operator's network). >>There is no point trying to fix the IPv6 facilities for tunnelling new >>extension headers. The people whose job it was to design this didn't do >>their job. Their design is now burned into IPv6 hardware processors >>everywhere. Full stop. >> >>All we can hope to do is ensure that CDO is not encrypted with ESP. That >>is feasible. >> >>Whatever we do, in many cases, the IPv6 header containing the CDO will >>be encapsulated in other IP headers. So ConEx functions will just have >>to live with that. To find CDO, they will have to look for an IP header >>that encapsulates an upper layer protocol header. And even then, they >>will have to look one level deeper in case IP headers start again. >>There's loads of kit these days that has to do that anyway (e.g. CGNATs >>looking for the transport header or DPI looking for the app-layer). This >>is all we can hope to do at this experimental stage. >I guess we should write this point more explicitly: >"A network node that assesses ConEx information=20 >SHOULD search for encapsulated IP headers until=20 >a CDO is found or no further IP headers can be found." (should or SHOULD?) SHOULD. But I wouldn't word the last clause like=20 that, because searching until no further IP=20 headers can be found could go on and on and on and on. How about: "A network node that assesses ConEx information=20 SHOULD search for encapsulated IP headers until a=20 CDO is found. At any specific network location,=20 the maximum necessary depth of search is likely=20 to be the same for all packets." ? >>We need to prove ConEx is useful, then it can be performance optimised. >>Header parsing performance is generally not a big problem these days. >> >> >>>>>>>* Suggested optional copying of CDO to outer, but also a simpler 'Do >>>>>>>not copy CDO' alternative. >>>>>>I don't really get you SHOULD NOT but MAY here...? >>>>> >>>>>See earlier. Tunnels don't normally understand dest opts, which is >>>>>why I >>>>>said SHOULD NOT. But the MAY is a performance optimisation. Am I >>>>>helping? >>>Okay, understood. But why SHOULD NOT? Isn't it sufficient to say >>>MAY...? (or even MUST/SHOULD if ConEx-aware...?) >> >>You're right, we could leave out the SHOULD NOT. I suggest: >> >>"As with any destination option, an ingress tunnel endpoint will not >>natively copy the CDO when adding an encapsulating outer IP header. >>However, it MAY..." > >Done. But one question: Why MAY and not SHOULD?=20 >Wouldn't it actually be nice if all future=20 >tunneling nodes would copy the header. See above about consistency, and ensuring it only=20 happens if the operator is fully aware of the=20 consequences. If it can't be a large majority, it's best not to be any= (IMO). HTH (Delayed 'cos it was a public holday in the UK yesterday.) Bob >>Bob >> >> >>>Mirja >>> >>> >>>>>>>=3D=3DSecurity Considerations=3D=3D >>>>>>> >>>>>>>* Added lots, all pointers to where security issues are discussed in >>>>>>>other places (which is what security directorate reviewers need). >>>>>>Okay I can add that if you think it's necessary (I would say it's just >>>>>>redundant, but you be might right that it just helps the sec dir). >>>>> >>>>>It's not always obvious which aspects relate to security. Especially >>>>>when the security is structural rather than crypto. So I think these >>>>>sentences are useful to sec dir. >>>>> >>>>> >>>>>>>=3D=3DIANA=3D=3D >>>>>>> >>>>>>>* I think the act bits need to be 00 not 10 to avoid ConEx packets >>>>>>>being dropped by non-ConEx nodes (including by non-ConEx receivers)? >>>>>>>But I'm willing to be corrected. >>>>>>I agree; Will ask Suresh why he has put a 10 though. >>>>> >>>>>Yes, he's the right guy to check with. >>>>> >>>>> >>>>>Bob >>>>> >>>>> >>>>>>Thanks, >>>>>>Mirja >>>>>> >>>>>>> >>>>>>> >>>>>>>Regards >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Bob >>>>> >>>>>{Note 1} >>>>>For anyone watching on the list, the tentative idea that Mirja has >>>>>reminded me of is documented in 11.3.1 of my PhD thesis entitled >>>>>"Covert >>>>>Markings as a Policer Signal". >>>>> >>>>>The potential problem: A ConEx policer punishes punishment. If a >>>>>congestion policer starts dropping packets because the user has >>>>>contributed excessively to congestion, in subsequent rounds the user >>>>>has >>>>>to re-echo 'L' markings for the policer drops as well. This can drive >>>>>the policer further into 'debit'. This might make it difficult for the >>>>>user to get out of trouble once she's started getting into trouble. >>>>> >>>>>The basic idea was that when a congestion policer drops packets >>>>>(because >>>>>the user is causing more congestion than her allowance), it will also >>>>>remove ConEx markings. Then (if there is some way for the receiver to >>>>>feed this back), the sender knows not to send more ConEx marks because >>>>>these aren't congestion drops, they are policer drops. >>>>> >>>>>We didn't that double punishment made it hard to get out of trouble in >>>>>any policer experiments so far, so let's not allow for a possible >>>>>solution to a problem that we probably don't even have. The current >>>>>crop >>>>>of ConEx drafts are experimental anyway. If this problem does surface, >>>>>then we can reconsider. >>>>> >>>>> >>>>> >>> >>>>>________________________________________________________________ >>>>>Bob Briscoe, BT >>> >>>-- >>>------------------------------------------ >>>Dipl.-Ing. Mirja K=FChlewind >>>Communication Systems Group >>>Institute TIK, ETH Z=FCrich >>>Gloriastrasse 35, 8092 Z=FCrich, Switzerland >>> >>>Room ETZ G93 >>>phone: +41 44 63 26932 >>>email: mirja.kuehlewind@tik.ee.ethz.ch >>>------------------------------------------ >> >>________________________________________________________________ >>Bob Briscoe, BT > >-- >------------------------------------------ >Dipl.-Ing. Mirja K=FChlewind >Communication Systems Group >Institute TIK, ETH Z=FCrich >Gloriastrasse 35, 8092 Z=FCrich, Switzerland > >Room ETZ G93 >phone: +41 44 63 26932 >email: mirja.kuehlewind@tik.ee.ethz.ch >------------------------------------------ ________________________________________________________________ Bob Briscoe, BT=20 From nobody Wed Aug 27 02:15:42 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 9E0AF1A03E2 for ; Wed, 27 Aug 2014 02:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 2fx3hB-ML4ks for ; Wed, 27 Aug 2014 02:15:37 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522DC1A03AC for ; Wed, 27 Aug 2014 02:15:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8026B107CF7; Wed, 27 Aug 2014 11:15:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lmTWOAH_qN3; Wed, 27 Aug 2014 11:15:35 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 6315A107B24; Wed, 27 Aug 2014 11:15:25 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.182]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 27 Aug 2014 11:15:25 +0200 From: Dirk Kutscher To: Nandita Dukkipati , Faisal Ghias Mir , Rolf Winter , Suresh Krishnan , Ying Zhang , "cjbc@it.uc3m.es" Thread-Topic: Comments on draft-ietf-conex-mobile-03 Thread-Index: AQHPpbk9SpMyE9MNi0KNLjgBGqJqfJusY4sAgDf/uzA= Date: Wed, 27 Aug 2014 09:15:25 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524991BA10D5@PALLENE.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.204] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/YXakREbBbQWLBGMgxyb9RD_T3z8 Cc: "conex@ietf.org" Subject: Re: [conex] Comments on draft-ietf-conex-mobile-03 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, 27 Aug 2014 09:15:39 -0000 VGhhbmtzIGEgbG90LCBOYW5kaXRhIC0tIHdlJ2xsIGFkZHJlc3MgdGhvc2UgY29tbWVudHMuDQoN CkJlc3QgcmVnYXJkcywNCkRpcmsNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBOYW5kaXRhIER1a2tpcGF0aSBbbWFpbHRvOm5hbmRpdGFkQGdvb2dsZS5jb21dDQo+IFNl bnQ6IERpZW5zdGFnLCAyMi4gSnVsaSAyMDE0IDIyOjA1DQo+IFRvOiBEaXJrIEt1dHNjaGVyOyBG YWlzYWwgR2hpYXMgTWlyOyBSb2xmIFdpbnRlcjsgU3VyZXNoIEtyaXNobmFuOyBZaW5nIFpoYW5n Ow0KPiBjamJjQGl0LnVjM20uZXMNCj4gQ2M6IGNvbmV4QGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNvbmV4LW1vYmlsZS0wMw0KPiANCj4gQ29udGludWlu ZyB3aXRoIHNvbWUgbW9yZSBjb21tZW50cy4uLg0KPiANCj4gU2VjdGlvbiAyIGlzIENvbkV4IHVz ZSBjYXNlcyBpbiBNb2JpbGUgQ29tbXVuaWNhdGlvbiBOZXR3b3Jrcywgd2hpbGUNCj4gU2VjdGlv biAzIGlzIENvbkV4IGluIEVQUy4gSXNuJ3QgQ29uRXggaW4gRVBTIGFsc28gYSBwYXJ0IG9mIHRo ZSBtb2JpbGUNCj4gY29tbXVuaWNhdGlvbiBuZXR3b3Jrcz8NCj4gSSBhbSBub3QgZ2V0dGluZyBp dDogd2hhdCBkaWQgeW91IGludGVuZCB0byBiZSB0aGUga2V5IGRpZmZlcmVuY2UgYmV0d2Vlbg0K PiBTZWN0aW9ucyAyIGFuZCAzLg0KPiANCj4gQXMgc3VjaCBteSBjb21tZW50IGZvciBTZWN0aW9u IDMgaXMgc2FtZSBhcyBiZWxvdyBmb3IgU2VjdGlvbiAyOg0KPiBleHBsYWluIHRoZSBwcm9ibGVt LCBhbmQgdGhlbiBsYXkgb3V0IHRoZSBDb25FeCBiYXNlZCBzb2x1dGlvbi9hcmNoaXRlY3R1cmUu DQo+IA0KPiBOYW5kaXRhDQo+IA0KPiBPbiBUdWUsIEp1bCAyMiwgMjAxNCBhdCAxMDoyOCBBTSwg TmFuZGl0YSBEdWtraXBhdGkgPG5hbmRpdGFkQGdvb2dsZS5jb20+DQo+IHdyb3RlOg0KPiA+IChh cyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKS4NCj4gPg0KPiA+IFN0aWxsIHJlYWRpbmcsIGJ1dCB3 YW50ZWQgdG8gcGFzcyBvbiBjb21tZW50cyBvbiBlYXJseSBwYXJ0IG9mIHRoZSBkcmFmdC4NCj4g Pg0KPiA+IEludHJvZHVjdGlvbg0KPiA+DQo+ID4gKiBUaGUgc2Vjb25kIHBhcmEgZGVzY3JpYmlu ZyBtZWFzdXJlbWVudHMgaW4gY2VsbHVsYXIgbmV0d29ya3M6IGlzDQo+ID4gdGhlcmUgYSByZWZl cmVuY2UgdG8gdGhlIGRhdGE/DQo+ID4NCj4gPiBTZWN0aW9uIDIuMSBDb25FeCBhcyBhIGJhc2lz IGZvciBUcmFmZmljIE1hbmFnZW1lbnQNCj4gPg0KPiA+ICogVGhlIHNlY29uZCBwYXJhIGdvZXMg aW50byBncmVhdCBkZXRhaWxzIG9uIFFvUyByZXF1aXJlbWVudHMgaW4gRVBTLA0KPiA+IHJhZGlv IGJlYXJlcnMgZXRjLi4uIGJ1dCB5b3UgbG9zdCBtZTogd2hhdCBpcyB0aGUgcG9pbnQgeW91IHdh bnQgdG8NCj4gPiBtYWtlPw0KPiA+DQo+ID4gKiBPbiByZWFkaW5nIGZ1cnRoZXIgaW50byBTZWN0 aW9uIDIuMSwgSSBhbSBqdXN0IG5vdCBnZXR0aW5nIHRoZSBoaWdoDQo+ID4gb3JkZXIgcG9pbnQg eW91IHdhbnQgdG8gbWFrZSBoZXJlLiBUaGUgdGV4dCBzd2l0Y2hlcyBiYWNrIGFuZCBmb3J0aA0K PiA+IGJldHdlZW4gZXhwbGFpbmluZyB0aGUgY3VycmVudCBzdGF0ZSBpbiBtb2JpbGUgbmV0d29y a3MgKERQSSBldGMuKSwNCj4gPiBhbmQgdGhhdCBDb25FeCBjYW4gYmUgdXNlZnVsLg0KPiA+DQo+ ID4gSW5zdGVhZCwgSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6IHNlcGFyYXRlIG91dCB0aGUgdHdv LiBGaXJzdCBjbGVhcmx5DQo+ID4gZXhwbGFpbiB0aGUgdHJhZmZpYyBtYW5hZ2VtZW50IHByb2Js ZW0gaW4gY2VsbHVsYXIgbmV0d29ya3MuIFRoZW4gZ28NCj4gPiBvbiB3aXRoIHRoZSBzcGVjaWZp Y3Mgb24gaG93IENvbkV4IGNhbiBiZSB1c2VkIHRvIGFkZHJlc3MgdGhlIHByb2JsZW1zDQo+ID4g bGFpZCBvdXQuDQo+ID4NCj4gPiBJIHRoaW5rIHRoZSBhYm92ZSBzcGxpdCB3aWxsIHNhdmUgdGhl IHJlYWRlcnMgYSBsb3Qgb2YgdGltZSBpbiB0cnlpbmcNCj4gPiB0byBwYXJzZSB0aHJvdWdoIFNl Yy4gMi4xDQo+ID4NCj4gPiBGdXJ0aGVyLCB0aGUgdXNlZnVsbmVzcyBvZiBDb25FeCBpcyByZWZl cnJlZCB0byBpbiB2ZXJ5IGhpZ2ggbGV2ZWwNCj4gPiB0ZXJtcyB3aXRoIGxpdHRsZSBkZXRhaWxz LiBHb2luZyBhIHN0ZXAgZnVydGhlciBhbmQgc3BlY2lmeWluZyBzb21lDQo+ID4gbGV2ZWwgb2Yg ZGV0YWlsIGFzIHRvIGhvdyBDb25FeCBtaWdodCBleGFjdGx5IHdvcmsgaW4gbW9iaWxlIHdpbGwg YmUNCj4gPiB1c2VmdWwuDQo+ID4NCj4gPiBOYW5kaXRhDQo= From nobody Thu Aug 28 08:44:10 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 96D991A870C for ; Thu, 28 Aug 2014 08:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, T_TVD_FUZZY_SECURITIES=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 GJ4YMs86sMHk for ; Thu, 28 Aug 2014 08:44:02 -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 2B9FE1A02E1 for ; Thu, 28 Aug 2014 08:44:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 495D8D930D; Thu, 28 Aug 2014 17:44:00 +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 Xz+sYkGZoUo9; Thu, 28 Aug 2014 17:44:00 +0200 (MEST) 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 F1F01D930B; Thu, 28 Aug 2014 17:43:59 +0200 (MEST) Message-ID: <53FF4E3F.4060502@tik.ee.ethz.ch> Date: Thu, 28 Aug 2014 17:43:59 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch> <53ECE917.6000803@tik.ee.ethz.ch> <201408141915.s7EJFVI8000808@bagheera.jungle.bt.co.uk> <53FB741A.9010500@tik.ee.ethz.ch> <201408261727.s7QHRlxB026767@bagheera.jungle.bt.co.uk> In-Reply-To: <201408261727.s7QHRlxB026767@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/rMcP9L2DYdw6C3SRkfj16QTe1ZI Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 28 Aug 2014 15:44:07 -0000 Hi Bob, again inline... On 26.08.2014 19:27, Bob Briscoe wrote: >>>>>>>> ==CDO== >>>>>>> >>>>>>>> * Specified precisely which IP header is included in the byte >>>>>>>> count. >>>>>>> So you suggest to not include any options? >>>>>> >>>>>> I didn't say that, did I? If the wording I used is ambiguous, pls >>>>>> fix it. >>>>>> >>>>>>> Why? I'd say you either include all bits because all of them >>>>>>> contribute to congestion, or none of the IP header bits because >>>>>>> that's >>>>>>> just the overhead you can't avoid if you what to send anything. Also >>>>>>> of course you can generate a larger percentage of overhead if you >>>>>>> send >>>>>>> smaller packets. >>>>>> >>>>>> That's why I think it is reasonable to include the IP header (and its >>>>>> options) that immediately encapsulates the ConEx dest opt. >>>>> Okay I misread your text. >>>>> >>>>> I just though, if you detect a CDO in the header you are currently >>>>> looking at, you will simply look at the playload length and next hop >>>>> fields of this header and than add another 40 bytes for the header >>>>> itself. But in fact that might be wrong if you have another IP header >>>>> encapsulated in the payload... so what is actually the right number of >>>>> bytes here? >>>>> >>>>> I was about to write the following but I'm not sure if that is >>>>> actually >>>>> write and/or clear: >>>>> "... IP packet (including the IP header that carries the CDO and all >>>>> associated options)..."? >>>>> That just doesn't say if you should look what the next header is and >>>>> subtract all other IP header bytes you can find. Is this needed? >>> >>> I'm happy with your something like your last sentence. For precision I >>> suggest rewording: >>> >>> IP packet (including the IP header that directly encapsulates the CDO >>> and everything that IP header encapsulates). >> Done >> >>> >>> It doesn't have to go searching for any more deeply encapsulated CDO. If >>> there is one, that will be dealt with by whatever higher layer it was >>> written in, at the point when the outer layers have been peeled off and >>> some function at that higher layer is processing these inner dest opts. >> My point actually was that you will get a different number of marked >> bytes if you look at a point with or without encapsulation. But as >> usually all packets (at least of the same flow) get encapsulated or >> not, the ratio between marked and not-marked bytes should still be the >> same, so I guess that's fine. > > Yup. When relative proportions are used, there's not a problem. > > Even where absolute packet size matters (e.g. a congestion policer or > more generally a policy device configured with a certain rate of > congestion allowance), the proposed definition can work,... as follows > > There are two possibilities where there might be a more deeply > encapsulated CDO: > i) Two independent systems are initiating different congestion feedback > loops, and they are both reinserting ConEx markings. > ii) The inner CDO has at some point been copied to the outer > > I was talking about case (i) before, where the sender and all policy > devices are working at their own layer on their own control loop, > unaware of another ConEx control loop at another layer (which is fine). > > Case (ii) could lead to a bias in the amount of congestion counted. This > is why I suggested that the only time a tunnel endpoint copies CDO to > the outer is as a performance optimisation. E.g. where an operator is > tunnelling packets across its own network and it knows there are ConEx > policy devices within its own network, so it saves them the hassle of > burying into the tunnel. > > So case (ii) is also fine, as long as the operator doing the > optimisation is aware of both its tunnels and its policy devices, and > configures the policy device to make the (constant) allowance for the > additional tunnel headers. > > Perhaps we need to add text where we suggest this optimisation to say > that the operator should ensure all packets are decapsulated back how > they were before passing on to another operator that is not aware of the > optimisation. But, this is getting over-detailed... > > > >>>>>>>> * Suggested deleting example of Not-ConEx-capable packets (see >>>>>>>> separate thread to conex-tcp-modifications authors about TCP pure >>>>>>>> ACKs). >>>>>>> I can remove the example but not sure why you are suggesting >>>>>>> this. If >>>>>>> you actually imply that the X bit should never be zero that we >>>>>>> have to >>>>>>> discuss if the X bit is needed at all. >>>>>> >>>>>> I have never thought the X flag was needed. There's probably some >>>>>> email >>>>>> on the list somewhere in the past from me that says that. >>>>>> >>>>>> As I put in one of the comment bubbles: >>>>>> "The only need I can see for the X-flag is if >>>>>> the Reserved field gets used in future for >>>>>> something in addition to ConEx. Then there >>>>>> would be a need to identify packets that >>>>>> are not ConEx-capable but still carry the >>>>>> CDO option (for the new reason)." >>>>>> >>>>>> Can anyone think of a use for the X flag? >>>>> I thought the X bit unset means: I'm a ConEx aware sender and i >>>>> want to >>>>> follow the rules but I don't have any feedback for this (control) data >>>>> so I'm unable to give you useful ConEx information and if you use this >>>>> packet for your estimation of the current congestion level, you might >>>>> underestimate it. >>>>> >>>>> Doesn't that make sense...? >>> >>> Not to me. What does "feedback for this (control) data" mean? Feedback >>> is about a path used by a 5-tuple. This control data is about to be sent >>> over such a path. If the sender has feedback about that path, the >>> feedback applies to everything sent over the path, at the IP layer, >>> whatever categorisation the next packet has at L4. >> If you do not get any feedback on a path, e.g. a receiver only sending >> ACKs, you will never be able to send any ConEx markings. So what's the >> point about marking a packet as ConEx-enabled? > > OK, this is a good example for when a ConEx-enabled flag might be > useful. However,... > > ...This doesn't justify marking pure ACKs as not-ConEx-enabled. If a > sender sends a pure ACK now, all it knows is that it might not have > enough feedback to be able to set ConEx markings on a whole sequence of > packets later in the flow,... but only if it keeps sending solely pure > ACKs from now on. However, a sender can't be sure that it won't have > enough feedback in future, because usually an app (let alone the > transport layer) cannot predict whether there will be more data to send > later, even if it's not sending any now. > > Once a sender has had no feedback for at least a round trip, it has 2 > options for subsequent packets: > a) turn off ConEx-enabled; > b) keep sending packets with ConEx-enabled set, but conservatively add > some credit. > > Even if it subsequently sends some data, it will still have to do (a) or > (b) on these data packets, at least for one further round trip, until it > gets the feedback. So this is nothing to do with whether the packet > being sent is a pure ACK. It is to do with whether feedback has recently > been received. Okay, rewrote the paragraph slightly: "If the X bit is zero all other three bits are undefined and thus should be ignored and forwarded unchanged by network nodes. The X bit set to zero means that the connection is ConEx-capable but this packet MUST NOT be accounted when determining ConEx information in an audit function. This can be the case if no feedback on the congestion status is (currently) available for e.g. for control packets (not carrying any user data). As an example a TCP receiver that only sends pure ACKs will usually send them as ACK are usually not ECN-capable as ACK usually are not ECN-capable and TCP does not have a mechanism to announce ACK lost. Thus congestion information about ACKs are not available." Is this okay? > > >> Further note, in the TCP mods we only look at the payload because we >> assume, for simplification, all packets have the same size. Therefore >> a packet that carries no data would not decrease the CEG/LEG. If ACKs >> should get marked, we need to rewrite all this stuff in the tcp mods >> doc... > > I don't think we should avoid changing tcp-mods if its 'not right'. > > I hope you see the problem from my explanation above - whether there is > enough feedback /now/ to ConEx-mark a packet has nothing to do with > whether the packet being sent /now/ is capable of generating feedback > /in the next round/. > > If you want to make a simplifying assumption, it is on the safe side for > a sender to assume that all incoming feedback is about packets of the > same size. It's not safe for a sender to assume that all packets it is > sending are the same size. Anyway, it knows what size it is sending, so > it doesn't need this simplification. Okay, the assumption is (only) that feedback is based on packets that are the same size. If we send you a packet we of course decrease the LEG/CEG by the actually payload bytes. But taking this assumption be simply do not account for headers at all (nor incoming neither outcoming) because we can anyway just estimated the header bits and there simply assume it will equal out. Which mean if we send a pure ACK we will not decrease the LEG/CEG because there are no payload bytes. I believe that this simplification makes thing much simpler and is therefore useful but will not allow for marking pure ACKs... You didn't convince me (yet) that this should be changed but this would need to be changed in the tcp mods doc and not this one anyway. > > The simplification I propose (that feedback is all about the same size > packets, rather than all the sent packets are the same size) is likely > to be pretty good, given the receiver doesn't get loss or ECN info about > pure ACKs, so they are automatically removed from the set of packets > that the sender assumes to be the same size. And, and if some of the > feedback is about smaller data packets, at least this simplification > will always be on the safe side. > > If I correctly understand the simplification you propose, a ConEx sender > will more often under-declare congestion than over-declaring, which is > not safe. I don't believe so. Was this just of a different understanding of what we proposed or can you explain further...? > > > >>> (Even if control data is somehow being sent over a different path, e.g. >>> using MPTCP or something, and there has never been feedback over that >>> path, then that would warrant Credit, not absence of ConEx.) >> I don't think credit does help here. Note credit cannot replace >> ConEx-markings anymore. > > OK, I should have said "then that would warrant conservatively sending > some credit and corresponding L or E markings." > > A sender can always send more ConEx marks than actual congestion, and if > it doesn't know actual congestion, it can at least hold an initial > estimate of what worst-case congestion might be (e.g. 1%). > > However, I admit that, if it only sends pure ACKs and this estimate is > too low, it will never know it is too low, and the audit function might > be dropping loads of its pure ACKs. Ug. This is a new issue I hadn't > thought of before... so I think we should recommend option a), not b). > >> And if you only send a small amount of control data, it is not very >> likely that your packets gets drop and thus probably you do not sent >> any credit. > > That's reasonable. > > > > > >>>>>>>> ==Fast-path== >>>>>>>> >>>>>>>> * CDO as first destination option: changed from MUST to SHOULD >>>>>>>> (with >>>>>>>> an example of when not to). >>>>>>> I believe this really needs to be a MUST. I know that might restrict >>>>>>> the use of ConEx with potential other options that might have the >>>>>>> same >>>>>>> requirement (for different reasons). But if you don't put a MUST >>>>>>> here, >>>>>>> you cannot implemented the suggested way in the fast path. >>>>>> >>>>>> A SHOULD still means it will be the first option in all current >>>>>> implementations. However, I suggest a SHOULD, precisely because >>>>>> performance reasons are not absolute, so they don't require a >>>>>> MUST. If >>>>>> another dest opt cannot work at all unless it is first, that would >>>>>> be a >>>>>> valid reason for CDO coming second, because it still works, it's >>>>>> /just/ >>>>>> slower. >>>>>> >>>>>> The IESG will (rightly) be very wary of any draft that says an option >>>>>> MUST be the first option. >>>>>> >>>>>> I suggested the following text after this: "(This is not >>>>>> stated as a 'MUST', because some future destination option might >>>>>> need to >>>>>> be placed first for functional rather than just performance >>>>>> reasons.)" >>>>> So our fast path implementation must simply assume that there is no >>>>> CDO >>>>> in case it cannot find it as the first option. Otherwise all non-ConEx >>>>> packets would need to go to the slow path to make sure there is no >>>>> ConEx >>>>> option. That means to me that this must be a MUST...? >>> >>> OK, I see the problem, but how much of a performance problem would it >>> really be for the fast path of a ConEx function to step along dest opts >>> until it gets to CDO then stops (rather than stop if CDO is not first)? >> So that's the different between you looking at one bit at a defined >> position or having a chain of conditional look-ups where the length is >> unknown. I believe that is something you would avoid to implement in >> fast path as the processing time is not fixed anymore... that would be >> my guess but I'm not an expert in this area. > > AFAICT, fast path implementations generally work along sequences of > extensions. So I don't think this is a problem. Bear in mind that we are > not asking general fast path forwarding implementations to do this. Only > ConEx functions specifically written to find the ConEx header.{Note 1} > > {Note 1} OK, we do suggest that general forwarding functions could do > DoS protection using the ConEx header. But that's stated as optional and > 'aspirational'. If such an experiment proves useful, you never know, > there could be demand for ConEx to migrate into the hop-by-hop options > (according to the v6 spec, hop-by-hop and dest options share the same > option number space, so this would be a straightforward migration, just > moving where the CDO is placed, but using the same option number and > format). There might be also further use cases for e.g. traffic management or multipath routing where general forwarding nodes need to access this information. So what's the solution here? > > >>> Then "CDO SHOULD be first" would give no different performance to "CDO >>> MUST be first", if CDO actually was first. If CDO had to be placed >>> second on a certain packet, "CDO SHOULD be first" would take just one >>> more op than "CDO MUST be first". >>> >>> Note: I've just re-read the spec of the IPv6 header. We need to specify >>> that CDO goes in the "Destination Options (before routing header)", not >>> the "Destination Options (before upper-layer header)". Then it won't be >>> encrypted by an ESP header. >> Thanks. I wasn't fully aware of this. But the difference for my >> understanding is if immediate node listed in the routing header should >> proceed this option or not. In our case it is probably not important >> which one we choose as it should be processed by none of the receivers. > > You're correct that CDO isn't processed by any of the nodes listed in > the routing header as destinations. The phrase "before routing header" > is just how its placement is described. We should clarify that this > isn't anything to do with the processing of the routing header. > >> Where did you read that the later one is not encrypted though? > > ESP encrypts everything after the ESP header, and it comes just before > the second dest opts. So it would be no good putting CDO after it. > > See the ESP spec, on "ESP Header Location": > > " The destination options extension header(s) could appear > either before or after the ESP header depending on the semantics > desired. However, since ESP protects only fields after the ESP > header, it generally may be desirable to place the destination > options header(s) after the ESP header. > " Thanks. Wasn't able to find this sentence! > > Also see the IPv6 spec on "Extension Header Order": > > > I believe one reason there are two places for the dest opt is because if > ESP is encrypting everything for the destination, it will normally be > expected that the dest opts need to be encrypted too. But this wouldn't > work if you have multiple destinations on the path in the routing header > (that probably don't hold the relevant key). Fortunately, this > exception is also needed for ConEx. > >> If so, I can simply add one sentence to the first paragraph of section 4: >> "The CDO MUST be placed in the destination option before routing >> header such that it does not get encrypted and can be read by >> immediate ConEx-aware nodes." >> And then remove the first paragraph of the IPSec section (and probably >> move the other paragraph somewhere else so that the section is removed >> completely)...? > > I've lost track of all the proposed changes to the IPsec section. But I > think there is value in spelling out exactly how ConEx and IPsec > interact, so I wouldn't remove the section completely, even if it > repeats info elsewhere. Okay I just realized that we recommend to to use TPSec for authentication but I believe if the ConEx option should not be encrypted by using the respective header, it will also not be authenticated...? So you can have either one of the two...? I believe we still need the IPSec section but right now I'm not sure what to right in there...? Any proposal? > >>>>>>>> ==IPsec compatibility== >>>>>>>> >>>>>>>> * Suggested ConEx counts the AH header, and the outer tunnel mode >>>>>>>> header, with reasoning. >>>>>>> Yes, need to be more precise. Will add. >>>>>> >>>>>> This one wasn't just clarity. I've actually contradicted what was >>>>>> said, >>>>>> so pls make sure there wasn't a good reason for why it was like it >>>>>> was. >>>>>> >>>>>> I was most concerned about suggesting this change, because it was the >>>>>> only one that caused a technical difference. >>>>> Ohh, I didn't read your comments carefully and was just looking at the >>>>> text changes... this whole accounting is a mess :-( >>> >>> I don't think it has to be, if we keep to the rule we just agreed above. >>> >>>>> Maybe we should only account the IPv6 header itself and the >>>>> destination >>>>> options...? >>> >>> Why? I really don't understand why the IPsec accounting was written like >>> it was. Pls explain. >> The problem about tunneling is that the number of ConEx marked bytes >> might be different depending on where at the path you look at the >> packets. But I guess that's less a problem than I initially though. If >> so I guess I can remove this paragraph about accounting in the IPSec >> section (if still needed at all). > > If you're saying that the new definition of what to count removes the > problem, because counting is no longer dependent on whether there are > encapsulating headers, I agree. Done. > >>>>> Moreover, isn't this here the same case than with tunneling in >>>>> general. >>>>> Only if the node that does the encapsulation is ConEx-aware it can >>>>> copy >>>>> the CDO, otherwise it will be not visible anymore. >>>>> >>>>> So this should either be a should, or we have to say something >>>>> like: if >>>>> the node is ConEx-aware is MUST copy the CDO...? >>>> And then we can the same thing for tunneling in general...? >>> >>> That's surely a circular argument. What would make a tunnel endpoint >>> into a ConEx-aware tunnel endpoint, so that it would have to copy the >>> CDO? It would only become ConEx-aware if it had code added to look for >>> the CDO, and why would it have that code added unless it was going to do >>> something with CDO? That's why I think my 'MAY copy as a performance >>> optimisation' formula is the best we can do. >> What you say above is the point. If the node does not know anything >> about ConEx, it simple cannot copy the option, which is the case for >> all currently existent nodes. So we cannot say MUST in general. But if >> the node does know that ConEx exists for any reason, it really must >> copy the CDO...? But you right that is a little pathologic. I'm will >> to change if that helps understanding/is less confusing. > > I think we're talking past each other. Given we cannot copy CDO to the > outer everywhere, for consistency I don't think that copying CDO to the > outer at all is a good idea, UNLESS it's done deliberately as part of an > operator's whole approach to handling ConEx. Ie. tunnel endpoints SHOULD > NOT copy CDO to the outer by default, but they MAY copy CDO to the outer > for a specific purpose (e.g. optimisation for ConEx functions elsewhere > in the same operator's network). Now understood. I've tried to make this point a little more clear, not sure if I succeeded: "As with any destination option, an ingress tunnel endpoint will not natively copy the CDO when adding an encapsulating outer IP header. In general an ingress tunnel SHOULD not copy the CDO to the outer header as this would changed the number of bytes that would be accounted. However, it MAY copy the CDO to the outer in order to facilitate visibility by subsequent on-path ConEx functions if the tunnel ingree is aware of these nodes and theses nodes are aware of the tunneling. This trades off the performance of ConEx functions against that of tunnel processing. " > > >>> There is no point trying to fix the IPv6 facilities for tunnelling new >>> extension headers. The people whose job it was to design this didn't do >>> their job. Their design is now burned into IPv6 hardware processors >>> everywhere. Full stop. >>> >>> All we can hope to do is ensure that CDO is not encrypted with ESP. That >>> is feasible. >>> >>> Whatever we do, in many cases, the IPv6 header containing the CDO will >>> be encapsulated in other IP headers. So ConEx functions will just have >>> to live with that. To find CDO, they will have to look for an IP header >>> that encapsulates an upper layer protocol header. And even then, they >>> will have to look one level deeper in case IP headers start again. >>> There's loads of kit these days that has to do that anyway (e.g. CGNATs >>> looking for the transport header or DPI looking for the app-layer). This >>> is all we can hope to do at this experimental stage. >> I guess we should write this point more explicitly: >> "A network node that assesses ConEx information SHOULD search for >> encapsulated IP headers until a CDO is found or no further IP headers >> can be found." (should or SHOULD?) > > SHOULD. But I wouldn't word the last clause like that, because searching > until no further IP headers can be found could go on and on and on and on. > > How about: > "A network node that assesses ConEx information SHOULD search for > encapsulated IP headers until a CDO is found. At any specific network > location, the maximum necessary depth of search is likely to be the same > for all packets." ? Done. > > > >>> We need to prove ConEx is useful, then it can be performance optimised. >>> Header parsing performance is generally not a big problem these days. >>> >>> >>>>>>>> * Suggested optional copying of CDO to outer, but also a simpler >>>>>>>> 'Do >>>>>>>> not copy CDO' alternative. >>>>>>> I don't really get you SHOULD NOT but MAY here...? >>>>>> >>>>>> See earlier. Tunnels don't normally understand dest opts, which is >>>>>> why I >>>>>> said SHOULD NOT. But the MAY is a performance optimisation. Am I >>>>>> helping? >>>> Okay, understood. But why SHOULD NOT? Isn't it sufficient to say >>>> MAY...? (or even MUST/SHOULD if ConEx-aware...?) >>> >>> You're right, we could leave out the SHOULD NOT. I suggest: >>> >>> "As with any destination option, an ingress tunnel endpoint will not >>> natively copy the CDO when adding an encapsulating outer IP header. >>> However, it MAY..." >> >> Done. But one question: Why MAY and not SHOULD? Wouldn't it actually >> be nice if all future tunneling nodes would copy the header. > > See above about consistency, and ensuring it only happens if the > operator is fully aware of the consequences. If it can't be a large > majority, it's best not to be any (IMO). See text above. Or do you want to add more text to this? Mirja > > HTH > (Delayed 'cos it was a public holday in the UK yesterday.) > > > Bob > > > > > >>> Bob >>> >>> >>>> Mirja >>>> >>>> >>>>>>>> ==Security Considerations== >>>>>>>> >>>>>>>> * Added lots, all pointers to where security issues are >>>>>>>> discussed in >>>>>>>> other places (which is what security directorate reviewers need). >>>>>>> Okay I can add that if you think it's necessary (I would say it's >>>>>>> just >>>>>>> redundant, but you be might right that it just helps the sec dir). >>>>>> >>>>>> It's not always obvious which aspects relate to security. Especially >>>>>> when the security is structural rather than crypto. So I think these >>>>>> sentences are useful to sec dir. >>>>>> >>>>>> >>>>>>>> ==IANA== >>>>>>>> >>>>>>>> * I think the act bits need to be 00 not 10 to avoid ConEx packets >>>>>>>> being dropped by non-ConEx nodes (including by non-ConEx >>>>>>>> receivers)? >>>>>>>> But I'm willing to be corrected. >>>>>>> I agree; Will ask Suresh why he has put a 10 though. >>>>>> >>>>>> Yes, he's the right guy to check with. >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Mirja >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bob >>>>>> >>>>>> {Note 1} >>>>>> For anyone watching on the list, the tentative idea that Mirja has >>>>>> reminded me of is documented in 11.3.1 of my PhD thesis entitled >>>>>> "Covert >>>>>> Markings as a Policer Signal". >>>>>> >>>>>> The potential problem: A ConEx policer punishes punishment. If a >>>>>> congestion policer starts dropping packets because the user has >>>>>> contributed excessively to congestion, in subsequent rounds the user >>>>>> has >>>>>> to re-echo 'L' markings for the policer drops as well. This can drive >>>>>> the policer further into 'debit'. This might make it difficult for >>>>>> the >>>>>> user to get out of trouble once she's started getting into trouble. >>>>>> >>>>>> The basic idea was that when a congestion policer drops packets >>>>>> (because >>>>>> the user is causing more congestion than her allowance), it will also >>>>>> remove ConEx markings. Then (if there is some way for the receiver to >>>>>> feed this back), the sender knows not to send more ConEx marks >>>>>> because >>>>>> these aren't congestion drops, they are policer drops. >>>>>> >>>>>> We didn't that double punishment made it hard to get out of >>>>>> trouble in >>>>>> any policer experiments so far, so let's not allow for a possible >>>>>> solution to a problem that we probably don't even have. The current >>>>>> crop >>>>>> of ConEx drafts are experimental anyway. If this problem does >>>>>> surface, >>>>>> then we can reconsider. >>>>>> >>>>>> >>>>>> >>>> >>>>>> ________________________________________________________________ >>>>>> Bob Briscoe, BT >>>> >>>> -- >>>> ------------------------------------------ >>>> 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 >>>> ------------------------------------------ >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT >> >> -- >> ------------------------------------------ >> 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 >> ------------------------------------------ > > ________________________________________________________________ > Bob Briscoe, BT -- ------------------------------------------ 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 Thu Aug 28 13:06:25 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 11D301A89EF for ; Thu, 28 Aug 2014 13:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 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.668, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=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 XZrLT0_pVjQr for ; Thu, 28 Aug 2014 13:06:16 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489231A89E7 for ; Thu, 28 Aug 2014 13:05:56 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 28 Aug 2014 21:05:52 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 28 Aug 2014 21:05:52 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 28 Aug 2014 21:05:50 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.133.183]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7SK5ke4004064; Thu, 28 Aug 2014 21:05:47 +0100 Message-ID: <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2014 21:05:44 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <53FF4E3F.4060502@tik.ee.ethz.ch> References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch> <53ECE917.6000803@tik.ee.ethz.ch> <201408141915.s7EJFVI8000808@bagheera.jungle.bt.co.uk> <53FB741A.9010500@tik.ee.ethz.ch> <201408261727.s7QHRlxB026767@bagheera.jungle.bt.co.uk> <53FF4E3F.4060502@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/XCuXzy1mMXDCU7JkiS3pBsNs8zc Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06 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, 28 Aug 2014 20:06:22 -0000 Mirja, At 16:43 28/08/2014, Mirja K=FChlewind wrote: >Hi Bob, > >again inline... > >On 26.08.2014 19:27, Bob Briscoe wrote: >>>>>>>>>=3D=3DCDO=3D=3D >>>>>>>> >>>>>>>>>* Specified precisely which IP header is included in the byte >>>>>>>>>count. >>>>>>>>So you suggest to not include any options? >>>>>>> >>>>>>>I didn't say that, did I? If the wording I used is ambiguous, pls >>>>>>>fix it. >>>>>>> >>>>>>>>Why? I'd say you either include all bits because all of them >>>>>>>>contribute to congestion, or none of the IP header bits because >>>>>>>>that's >>>>>>>>just the overhead you can't avoid if you what to send anything. Also >>>>>>>>of course you can generate a larger percentage of overhead if you >>>>>>>>send >>>>>>>>smaller packets. >>>>>>> >>>>>>>That's why I think it is reasonable to include the IP header (and its >>>>>>>options) that immediately encapsulates the ConEx dest opt. >>>>>>Okay I misread your text. >>>>>> >>>>>>I just though, if you detect a CDO in the header you are currently >>>>>>looking at, you will simply look at the playload length and next hop >>>>>>fields of this header and than add another 40 bytes for the header >>>>>>itself. But in fact that might be wrong if you have another IP header >>>>>>encapsulated in the payload... so what is actually the right number of >>>>>>bytes here? >>>>>> >>>>>>I was about to write the following but I'm not sure if that is >>>>>>actually >>>>>>write and/or clear: >>>>>>"... IP packet (including the IP header that carries the CDO and all >>>>>>associated options)..."? >>>>>>That just doesn't say if you should look what the next header is and >>>>>>subtract all other IP header bytes you can find. Is this needed? >>>> >>>>I'm happy with your something like your last sentence. For precision I >>>>suggest rewording: >>>> >>>>IP packet (including the IP header that directly encapsulates the CDO >>>>and everything that IP header encapsulates). >>>Done >>> >>>> >>>>It doesn't have to go searching for any more deeply encapsulated CDO. If >>>>there is one, that will be dealt with by whatever higher layer it was >>>>written in, at the point when the outer layers have been peeled off and >>>>some function at that higher layer is processing these inner dest opts. >>>My point actually was that you will get a different number of marked >>>bytes if you look at a point with or without encapsulation. But as >>>usually all packets (at least of the same flow) get encapsulated or >>>not, the ratio between marked and not-marked bytes should still be the >>>same, so I guess that's fine. >> >>Yup. When relative proportions are used, there's not a problem. >> >>Even where absolute packet size matters (e.g. a congestion policer or >>more generally a policy device configured with a certain rate of >>congestion allowance), the proposed definition can work,... as follows >> >>There are two possibilities where there might be a more deeply >>encapsulated CDO: >>i) Two independent systems are initiating different congestion feedback >>loops, and they are both reinserting ConEx markings. >>ii) The inner CDO has at some point been copied to the outer >> >>I was talking about case (i) before, where the sender and all policy >>devices are working at their own layer on their own control loop, >>unaware of another ConEx control loop at another layer (which is fine). >> >>Case (ii) could lead to a bias in the amount of congestion counted. This >>is why I suggested that the only time a tunnel endpoint copies CDO to >>the outer is as a performance optimisation. E.g. where an operator is >>tunnelling packets across its own network and it knows there are ConEx >>policy devices within its own network, so it saves them the hassle of >>burying into the tunnel. >> >>So case (ii) is also fine, as long as the operator doing the >>optimisation is aware of both its tunnels and its policy devices, and >>configures the policy device to make the (constant) allowance for the >>additional tunnel headers. >> >>Perhaps we need to add text where we suggest this optimisation to say >>that the operator should ensure all packets are decapsulated back how >>they were before passing on to another operator that is not aware of the >>optimisation. But, this is getting over-detailed... >> >> >> >>>>>>>>>* Suggested deleting example of Not-ConEx-capable packets (see >>>>>>>>>separate thread to conex-tcp-modifications authors about TCP pure >>>>>>>>>ACKs). >>>>>>>>I can remove the example but not sure why you are suggesting >>>>>>>>this. If >>>>>>>>you actually imply that the X bit should never be zero that we >>>>>>>>have to >>>>>>>>discuss if the X bit is needed at all. >>>>>>> >>>>>>>I have never thought the X flag was needed. There's probably some >>>>>>>email >>>>>>>on the list somewhere in the past from me that says that. >>>>>>> >>>>>>>As I put in one of the comment bubbles: >>>>>>>"The only need I can see for the X-flag is if >>>>>>>the Reserved field gets used in future for >>>>>>>something in addition to ConEx. Then there >>>>>>>would be a need to identify packets that >>>>>>>are not ConEx-capable but still carry the >>>>>>>CDO option (for the new reason)." >>>>>>> >>>>>>>Can anyone think of a use for the X flag? >>>>>>I thought the X bit unset means: I'm a ConEx aware sender and i >>>>>>want to >>>>>>follow the rules but I don't have any feedback for this (control) data >>>>>>so I'm unable to give you useful ConEx information and if you use this >>>>>>packet for your estimation of the current congestion level, you might >>>>>>underestimate it. >>>>>> >>>>>>Doesn't that make sense...? >>>> >>>>Not to me. What does "feedback for this (control) data" mean? Feedback >>>>is about a path used by a 5-tuple. This control data is about to be sent >>>>over such a path. If the sender has feedback about that path, the >>>>feedback applies to everything sent over the path, at the IP layer, >>>>whatever categorisation the next packet has at L4. >>>If you do not get any feedback on a path, e.g. a receiver only sending >>>ACKs, you will never be able to send any ConEx markings. So what's the >>>point about marking a packet as ConEx-enabled? >> >>OK, this is a good example for when a ConEx-enabled flag might be >>useful. However,... >> >>...This doesn't justify marking pure ACKs as not-ConEx-enabled. If a >>sender sends a pure ACK now, all it knows is that it might not have >>enough feedback to be able to set ConEx markings on a whole sequence of >>packets later in the flow,... but only if it keeps sending solely pure >>ACKs from now on. However, a sender can't be sure that it won't have >>enough feedback in future, because usually an app (let alone the >>transport layer) cannot predict whether there will be more data to send >>later, even if it's not sending any now. >> >>Once a sender has had no feedback for at least a round trip, it has 2 >>options for subsequent packets: >>a) turn off ConEx-enabled; >>b) keep sending packets with ConEx-enabled set, but conservatively add >>some credit. >> >>Even if it subsequently sends some data, it will still have to do (a) or >>(b) on these data packets, at least for one further round trip, until it >>gets the feedback. So this is nothing to do with whether the packet >>being sent is a pure ACK. It is to do with whether feedback has recently >>been received. > >Okay, rewrote the paragraph slightly: > >"If the X bit is zero all other three bits are=20 >undefined and thus should be ignored and=20 >forwarded unchanged by network nodes. The X bit=20 >set to zero means that the connection is=20 >ConEx-capable but this packet MUST NOT be=20 >accounted when determining ConEx information in=20 >an audit function. This can be the case if no=20 >feedback on the congestion status is (currently)=20 >available for e.g. for control packets (not=20 >carrying any user data). As an example a TCP=20 >receiver that only sends pure ACKs will usually=20 >send them as ACK are usually not ECN-capable as=20 >ACK usually are not ECN-capable and TCP does not=20 >have a mechanism to announce ACK lost. Thus=20 >congestion information about ACKs are not available." > >Is this okay? The main problem is saying 'not available *for*=20 control packets'. But just changing 'for' to=20 'from' would still make this too unclear to be understood. Also need to: * Make it clear the example is TCP-specific. * Focus on loss first, then ECN. * 'mechanism to announce ACK loss' is not really understandable. * Avoid 'control packets', which is too general,=20 given this is an example, so it can be specific. * Nit: duplicated word (for e.g. for) and=20 duplicated phrase (as ACK are usually not=20 ECN-capable as ACK usually are not ECN-capable). How about: First 2 sentences unchanged, then... "This can be the case if no congestion feedback=20 is (currently) available e.g. in TCP if one=20 endpoint has been receiving data but sending=20 nothing but pure ACKs (no user data) for some=20 time. This is because pure ACKs do not advance=20 the sequence number, so the TCP endpoint=20 receiving them cannot reliably tell whether any=20 have been lost due to congestion. Pure TCP ACKs=20 cannot be ECN-marked either [RFC3168]." >>>Further note, in the TCP mods we only look at the payload because we >>>assume, for simplification, all packets have the same size. Therefore >>>a packet that carries no data would not decrease the CEG/LEG. If ACKs >>>should get marked, we need to rewrite all this stuff in the tcp mods >>>doc... >> >>I don't think we should avoid changing tcp-mods if its 'not right'. >> >>I hope you see the problem from my explanation above - whether there is >>enough feedback /now/ to ConEx-mark a packet has nothing to do with >>whether the packet being sent /now/ is capable of generating feedback >>/in the next round/. >> >>If you want to make a simplifying assumption, it is on the safe side for >>a sender to assume that all incoming feedback is about packets of the >>same size. It's not safe for a sender to assume that all packets it is >>sending are the same size. Anyway, it knows what size it is sending, so >>it doesn't need this simplification. >Okay, the assumption is (only) that feedback is=20 >based on packets that are the same size. If we=20 >send you a packet we of course decrease the=20 >LEG/CEG by the actually payload bytes. But=20 >taking this assumption be simply do not account=20 >for headers at all (nor incoming neither=20 >outcoming) because we can anyway just estimated=20 >the header bits and there simply assume it will=20 >equal out. Which mean if we send a pure ACK we=20 >will not decrease the LEG/CEG because there are=20 >no payload bytes. I believe that this=20 >simplification makes thing much simpler and is=20 >therefore useful but will not allow for marking pure ACKs... I thought the earlier definition said that ConEx=20 accounts for the size of the IP header that=20 contains the CDO and everything within it. Also,=20 there's the TCP header size on a pure ACK. That's the basis on which I am assuming that pure=20 ACKs are worth counting. A pure ACK will count as=20 at least 86B (and more if there are additional TCP options or IP= extensions). IPv6 header: 40B CDO dest opt: 6B TCP header: 40B Total: 86B If there are more IP extensions, I guess it will=20 be hard for TCP to know though. >You didn't convince me (yet) that this should be=20 >changed but this would need to be changed in the=20 >tcp mods doc and not this one anyway. Agreed (that this would affect tcp-mods, not destopt). What is 'this' that you aren't yet convinced by? >>The simplification I propose (that feedback is all about the same size >>packets, rather than all the sent packets are the same size) is likely >>to be pretty good, given the receiver doesn't get loss or ECN info about >>pure ACKs, so they are automatically removed from the set of packets >>that the sender assumes to be the same size. And, and if some of the >>feedback is about smaller data packets, at least this simplification >>will always be on the safe side. >> >>If I correctly understand the simplification you propose, a ConEx sender >>will more often under-declare congestion than over-declaring, which is >>not safe. >I don't believe so. Was this just of a different=20 >understanding of what we proposed or can you explain further...? I thought you were proposing that a TCP sender=20 assumes all the packets it sends are full-sized,=20 even if they aren't. But I believe you have said that is not what you= proposed. >>>>(Even if control data is somehow being sent over a different path, e.g. >>>>using MPTCP or something, and there has never been feedback over that >>>>path, then that would warrant Credit, not absence of ConEx.) >>>I don't think credit does help here. Note credit cannot replace >>>ConEx-markings anymore. >> >>OK, I should have said "then that would warrant conservatively sending >>some credit and corresponding L or E markings." >> >>A sender can always send more ConEx marks than actual congestion, and if >>it doesn't know actual congestion, it can at least hold an initial >>estimate of what worst-case congestion might be (e.g. 1%). >> >>However, I admit that, if it only sends pure ACKs and this estimate is >>too low, it will never know it is too low, and the audit function might >>be dropping loads of its pure ACKs. Ug. This is a new issue I hadn't >>thought of before... so I think we should recommend option a), not b). >> >>> And if you only send a small amount of control data, it is not very >>>likely that your packets gets drop and thus probably you do not sent >>>any credit. >> >>That's reasonable. >> >> >> >> >> >>>>>>>>>=3D=3DFast-path=3D=3D >>>>>>>>> >>>>>>>>>* CDO as first destination option: changed from MUST to SHOULD >>>>>>>>>(with >>>>>>>>>an example of when not to). >>>>>>>>I believe this really needs to be a MUST. I know that might restrict >>>>>>>>the use of ConEx with potential other options that might have the >>>>>>>>same >>>>>>>>requirement (for different reasons). But if you don't put a MUST >>>>>>>>here, >>>>>>>>you cannot implemented the suggested way in the fast path. >>>>>>> >>>>>>>A SHOULD still means it will be the first option in all current >>>>>>>implementations. However, I suggest a SHOULD, precisely because >>>>>>>performance reasons are not absolute, so they don't require a >>>>>>>MUST. If >>>>>>>another dest opt cannot work at all unless it is first, that would >>>>>>>be a >>>>>>>valid reason for CDO coming second, because it still works, it's >>>>>>>/just/ >>>>>>>slower. >>>>>>> >>>>>>>The IESG will (rightly) be very wary of any draft that says an option >>>>>>>MUST be the first option. >>>>>>> >>>>>>>I suggested the following text after this: "(This is not >>>>>>>stated as a 'MUST', because some future destination option might >>>>>>>need to >>>>>>>be placed first for functional rather than just performance >>>>>>>reasons.)" >>>>>>So our fast path implementation must simply assume that there is no >>>>>>CDO >>>>>>in case it cannot find it as the first option. Otherwise all non-ConEx >>>>>>packets would need to go to the slow path to make sure there is no >>>>>>ConEx >>>>>>option. That means to me that this must be a MUST...? >>>> >>>>OK, I see the problem, but how much of a performance problem would it >>>>really be for the fast path of a ConEx function to step along dest opts >>>>until it gets to CDO then stops (rather than stop if CDO is not first)? >>>So that's the different between you looking at one bit at a defined >>>position or having a chain of conditional look-ups where the length is >>>unknown. I believe that is something you would avoid to implement in >>>fast path as the processing time is not fixed anymore... that would be >>>my guess but I'm not an expert in this area. >> >>AFAICT, fast path implementations generally work along sequences of >>extensions. So I don't think this is a problem. Bear in mind that we are >>not asking general fast path forwarding implementations to do this. Only >>ConEx functions specifically written to find the ConEx header.{Note 1} >> >>{Note 1} OK, we do suggest that general forwarding functions could do >>DoS protection using the ConEx header. But that's stated as optional and >>'aspirational'. If such an experiment proves useful, you never know, >>there could be demand for ConEx to migrate into the hop-by-hop options >>(according to the v6 spec, hop-by-hop and dest options share the same >>option number space, so this would be a straightforward migration, just >>moving where the CDO is placed, but using the same option number and >>format). > >There might be also further use cases for e.g.=20 >traffic management or multipath routing where=20 >general forwarding nodes need to access this information. > >So what's the solution here? I think this will get thrown back by the IESG if=20 we say 'MUST be first'. And I think 'SHOULD be=20 first' is a doable implementation for ConEx-aware=20 nodes. That is sufficient for experimental. Any=20 experiments where general forwarding nodes access=20 ConEx will already be reading a destopt at every=20 hop, which is not what was intended, but it would=20 be doable just for an experiment that wanted to prove ConEx has wider uses. Everyone involved in IPv6 knows that the attempt=20 to design extensibility into v6 failed. It won't=20 be news to the IESG that we can't add an=20 extension that can be processed at every hop on the fast path. If a destopt is sufficient to prove ConEx useful,=20 then implementers will want to satisfy this demand. Then * either there is even more pressure on the IETF=20 to address this failing in v6 (and maybe someone will), * or ConEx has to continue with this destopt=20 solution, just like everyone else is finding hacks round this failing in v6. But don't ask me. Ask Suresh. >>>>Then "CDO SHOULD be first" would give no different performance to "CDO >>>>MUST be first", if CDO actually was first. If CDO had to be placed >>>>second on a certain packet, "CDO SHOULD be first" would take just one >>>>more op than "CDO MUST be first". >>>> >>>>Note: I've just re-read the spec of the IPv6 header. We need to specify >>>>that CDO goes in the "Destination Options (before routing header)", not >>>>the "Destination Options (before upper-layer header)". Then it won't be >>>>encrypted by an ESP header. >>>Thanks. I wasn't fully aware of this. But the difference for my >>>understanding is if immediate node listed in the routing header should >>>proceed this option or not. In our case it is probably not important >>>which one we choose as it should be processed by none of the receivers. >> >>You're correct that CDO isn't processed by any of the nodes listed in >>the routing header as destinations. The phrase "before routing header" >>is just how its placement is described. We should clarify that this >>isn't anything to do with the processing of the routing header. >> >>>Where did you read that the later one is not encrypted though? >> >>ESP encrypts everything after the ESP header, and it comes just before >>the second dest opts. So it would be no good putting CDO after it. >> >>See the ESP spec, on "ESP Header Location": >> >>" The destination options extension header(s) could appear >> either before or after the ESP header depending on the semantics >> desired. However, since ESP protects only fields after the ESP >> header, it generally may be desirable to place the destination >> options header(s) after the ESP header. >>" >Thanks. Wasn't able to find this sentence! > >> >>Also see the IPv6 spec on "Extension Header Order": >> >> >>I believe one reason there are two places for the dest opt is because if >>ESP is encrypting everything for the destination, it will normally be >>expected that the dest opts need to be encrypted too. But this wouldn't >>work if you have multiple destinations on the path in the routing header >>(that probably don't hold the relevant key). Fortunately, this >>exception is also needed for ConEx. >> >>>If so, I can simply add one sentence to the first paragraph of section 4: >>>"The CDO MUST be placed in the destination option before routing >>>header such that it does not get encrypted and can be read by >>>immediate ConEx-aware nodes." >>>And then remove the first paragraph of the IPSec section (and probably >>>move the other paragraph somewhere else so that the section is removed >>>completely)...? >> >>I've lost track of all the proposed changes to the IPsec section. But I >>think there is value in spelling out exactly how ConEx and IPsec >>interact, so I wouldn't remove the section completely, even if it >>repeats info elsewhere. > >Okay I just realized that we recommend to to use=20 >TPSec for authentication but I believe if the=20 >ConEx option should not be encrypted by using=20 >the respective header, it will also not be=20 >authenticated...? So you can have either one of=20 >the two...? I believe we still need the IPSec=20 >section but right now I'm not sure what to right in there...? Any proposal? * How to do ConEx when IPsec is also required=20 (tunnel & transport modes, and what to count).=20 This may all be obvious now, but (IMO) it would=20 still be worth spelling out obvious things. * How to use IPsec to protect the integrity of CDO. >>>>>>>>>=3D=3DIPsec compatibility=3D=3D >>>>>>>>> >>>>>>>>>* Suggested ConEx counts the AH header, and the outer tunnel mode >>>>>>>>>header, with reasoning. >>>>>>>>Yes, need to be more precise. Will add. >>>>>>> >>>>>>>This one wasn't just clarity. I've actually contradicted what was >>>>>>>said, >>>>>>>so pls make sure there wasn't a good reason for why it was like it >>>>>>>was. >>>>>>> >>>>>>>I was most concerned about suggesting this change, because it was the >>>>>>>only one that caused a technical difference. >>>>>>Ohh, I didn't read your comments carefully and was just looking at the >>>>>>text changes... this whole accounting is a mess :-( >>>> >>>>I don't think it has to be, if we keep to the rule we just agreed above. >>>> >>>>>>Maybe we should only account the IPv6 header itself and the >>>>>>destination >>>>>>options...? >>>> >>>>Why? I really don't understand why the IPsec accounting was written like >>>>it was. Pls explain. >>>The problem about tunneling is that the number of ConEx marked bytes >>>might be different depending on where at the path you look at the >>>packets. But I guess that's less a problem than I initially though. If >>>so I guess I can remove this paragraph about accounting in the IPSec >>>section (if still needed at all). >> >>If you're saying that the new definition of what to count removes the >>problem, because counting is no longer dependent on whether there are >>encapsulating headers, I agree. > >Done. > >> >>>>>>Moreover, isn't this here the same case than with tunneling in >>>>>>general. >>>>>>Only if the node that does the encapsulation is ConEx-aware it can >>>>>>copy >>>>>>the CDO, otherwise it will be not visible anymore. >>>>>> >>>>>>So this should either be a should, or we have to say something >>>>>>like: if >>>>>>the node is ConEx-aware is MUST copy the CDO...? >>>>>And then we can the same thing for tunneling in general...? >>>> >>>>That's surely a circular argument. What would make a tunnel endpoint >>>>into a ConEx-aware tunnel endpoint, so that it would have to copy the >>>>CDO? It would only become ConEx-aware if it had code added to look for >>>>the CDO, and why would it have that code added unless it was going to do >>>>something with CDO? That's why I think my 'MAY copy as a performance >>>>optimisation' formula is the best we can do. >>>What you say above is the point. If the node does not know anything >>>about ConEx, it simple cannot copy the option, which is the case for >>>all currently existent nodes. So we cannot say MUST in general. But if >>>the node does know that ConEx exists for any reason, it really must >>>copy the CDO...? But you right that is a little pathologic. I'm will >>>to change if that helps understanding/is less confusing. >> >>I think we're talking past each other. Given we cannot copy CDO to the >>outer everywhere, for consistency I don't think that copying CDO to the >>outer at all is a good idea, UNLESS it's done deliberately as part of an >>operator's whole approach to handling ConEx. Ie. tunnel endpoints SHOULD >>NOT copy CDO to the outer by default, but they MAY copy CDO to the outer >>for a specific purpose (e.g. optimisation for ConEx functions elsewhere >>in the same operator's network). >Now understood. > >I've tried to make this point a little more clear, not sure if I succeeded: >"As with any destination option, an ingress=20 >tunnel endpoint will not natively copy the CDO=20 >when adding an encapsulating outer IP header. In=20 >general an ingress tunnel SHOULD not copy the=20 >CDO to the outer header as this would changed=20 >the number of bytes that would be accounted.=20 >However, it MAY copy the CDO to the outer in=20 >order to facilitate visibility by subsequent=20 >on-path ConEx functions if the tunnel ingree is=20 >aware of these nodes and theses nodes are aware=20 >of the tunneling. This trades off the=20 >performance of ConEx functions against that of tunnel processing. " OK. Rather than implying that equipment has=20 evolved conscious awareness, a better formulation would be something like: "..the configuration of the tunnel ingress and=20 the ConEx nodes is co-ordinated." Nits: s/SHOULD not/SHOULD NOT/ s/accounted/counted/ (in English, accounted is not a transitive=20 verb, it has to have 'for' after it) s/ingree/ingress/ s/theses/these/ >>>>There is no point trying to fix the IPv6 facilities for tunnelling new >>>>extension headers. The people whose job it was to design this didn't do >>>>their job. Their design is now burned into IPv6 hardware processors >>>>everywhere. Full stop. >>>> >>>>All we can hope to do is ensure that CDO is not encrypted with ESP. That >>>>is feasible. >>>> >>>>Whatever we do, in many cases, the IPv6 header containing the CDO will >>>>be encapsulated in other IP headers. So ConEx functions will just have >>>>to live with that. To find CDO, they will have to look for an IP header >>>>that encapsulates an upper layer protocol header. And even then, they >>>>will have to look one level deeper in case IP headers start again. >>>>There's loads of kit these days that has to do that anyway (e.g. CGNATs >>>>looking for the transport header or DPI looking for the app-layer). This >>>>is all we can hope to do at this experimental stage. >>>I guess we should write this point more explicitly: >>>"A network node that assesses ConEx information SHOULD search for >>>encapsulated IP headers until a CDO is found or no further IP headers >>>can be found." (should or SHOULD?) >> >>SHOULD. But I wouldn't word the last clause like that, because searching >>until no further IP headers can be found could go on and on and on and on. >> >>How about: >>"A network node that assesses ConEx information SHOULD search for >>encapsulated IP headers until a CDO is found. At any specific network >>location, the maximum necessary depth of search is likely to be the same >>for all packets." ? > >Done. > >> >> >> >>>>We need to prove ConEx is useful, then it can be performance optimised. >>>>Header parsing performance is generally not a big problem these days. >>>> >>>> >>>>>>>>>* Suggested optional copying of CDO to outer, but also a simpler >>>>>>>>>'Do >>>>>>>>>not copy CDO' alternative. >>>>>>>>I don't really get you SHOULD NOT but MAY here...? >>>>>>> >>>>>>>See earlier. Tunnels don't normally understand dest opts, which is >>>>>>>why I >>>>>>>said SHOULD NOT. But the MAY is a performance optimisation. Am I >>>>>>>helping? >>>>>Okay, understood. But why SHOULD NOT? Isn't it sufficient to say >>>>>MAY...? (or even MUST/SHOULD if ConEx-aware...?) >>>> >>>>You're right, we could leave out the SHOULD NOT. I suggest: >>>> >>>>"As with any destination option, an ingress tunnel endpoint will not >>>>natively copy the CDO when adding an encapsulating outer IP header. >>>>However, it MAY..." >>> >>>Done. But one question: Why MAY and not SHOULD? Wouldn't it actually >>>be nice if all future tunneling nodes would copy the header. >> >>See above about consistency, and ensuring it only happens if the >>operator is fully aware of the consequences. If it can't be a large >>majority, it's best not to be any (IMO). > >See text above. Or do you want to add more text to this? Nope, no need for more. We're getting there! But we really do need Suresh's expert eye on this. Cheers Bob >Mirja > >> >>HTH >>(Delayed 'cos it was a public holday in the UK yesterday.) >> >> >>Bob >> >> >> >> >> >>>>Bob >>>> >>>> >>>>>Mirja >>>>> >>>>> >>>>>>>>>=3D=3DSecurity Considerations=3D=3D >>>>>>>>> >>>>>>>>>* Added lots, all pointers to where security issues are >>>>>>>>>discussed in >>>>>>>>>other places (which is what security directorate reviewers need). >>>>>>>>Okay I can add that if you think it's necessary (I would say it's >>>>>>>>just >>>>>>>>redundant, but you be might right that it just helps the sec dir). >>>>>>> >>>>>>>It's not always obvious which aspects relate to security. Especially >>>>>>>when the security is structural rather than crypto. So I think these >>>>>>>sentences are useful to sec dir. >>>>>>> >>>>>>> >>>>>>>>>=3D=3DIANA=3D=3D >>>>>>>>> >>>>>>>>>* I think the act bits need to be 00 not 10 to avoid ConEx packets >>>>>>>>>being dropped by non-ConEx nodes (including by non-ConEx >>>>>>>>>receivers)? >>>>>>>>>But I'm willing to be corrected. >>>>>>>>I agree; Will ask Suresh why he has put a 10 though. >>>>>>> >>>>>>>Yes, he's the right guy to check with. >>>>>>> >>>>>>> >>>>>>>Bob >>>>>>> >>>>>>> >>>>>>>>Thanks, >>>>>>>>Mirja >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>Regards >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>Bob >>>>>>> >>>>>>>{Note 1} >>>>>>>For anyone watching on the list, the tentative idea that Mirja has >>>>>>>reminded me of is documented in 11.3.1 of my PhD thesis entitled >>>>>>>"Covert >>>>>>>Markings as a Policer Signal". >>>>>>> >>>>>>>The potential problem: A ConEx policer punishes punishment. If a >>>>>>>congestion policer starts dropping packets because the user has >>>>>>>contributed excessively to congestion, in subsequent rounds the user >>>>>>>has >>>>>>>to re-echo 'L' markings for the policer drops as well. This can drive >>>>>>>the policer further into 'debit'. This might make it difficult for >>>>>>>the >>>>>>>user to get out of trouble once she's started getting into trouble. >>>>>>> >>>>>>>The basic idea was that when a congestion policer drops packets >>>>>>>(because >>>>>>>the user is causing more congestion than her allowance), it will also >>>>>>>remove ConEx markings. Then (if there is some way for the receiver to >>>>>>>feed this back), the sender knows not to send more ConEx marks >>>>>>>because >>>>>>>these aren't congestion drops, they are policer drops. >>>>>>> >>>>>>>We didn't that double punishment made it hard to get out of >>>>>>>trouble in >>>>>>>any policer experiments so far, so let's not allow for a possible >>>>>>>solution to a problem that we probably don't even have. The current >>>>>>>crop >>>>>>>of ConEx drafts are experimental anyway. If this problem does >>>>>>>surface, >>>>>>>then we can reconsider. >>>>>>> >>>>>>> >>>>> >>>>>>>________________________________________________________________ >>>>>>>Bob Briscoe, BT >>>>> >>>>>-- >>>>>------------------------------------------ >>>>>Dipl.-Ing. Mirja K=FChlewind >>>>>Communication Systems Group >>>>>Institute TIK, ETH Z=FCrich >>>>>Gloriastrasse 35, 8092 Z=FCrich, Switzerland >>>>> >>>>>Room ETZ G93 >>>>>phone: +41 44 63 26932 >>>>>email: mirja.kuehlewind@tik.ee.ethz.ch >>>>>------------------------------------------ >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT >>> >>>-- >>>------------------------------------------ >>>Dipl.-Ing. Mirja K=FChlewind >>>Communication Systems Group >>>Institute TIK, ETH Z=FCrich >>>Gloriastrasse 35, 8092 Z=FCrich, Switzerland >>> >>>Room ETZ G93 >>>phone: +41 44 63 26932 >>>email: mirja.kuehlewind@tik.ee.ethz.ch >>>------------------------------------------ >> >>________________________________________________________________ >>Bob Briscoe, BT > >-- >------------------------------------------ >Dipl.-Ing. Mirja K=FChlewind >Communication Systems Group >Institute TIK, ETH Z=FCrich >Gloriastrasse 35, 8092 Z=FCrich, Switzerland > >Room ETZ G93 >phone: +41 44 63 26932 >email: mirja.kuehlewind@tik.ee.ethz.ch >------------------------------------------ ________________________________________________________________ Bob Briscoe, BT=20