From nobody Wed Sep 3 08:57:30 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 DFEC31A8770 for ; Wed, 3 Sep 2014 08:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 hxUF_0FyPYWO for ; Wed, 3 Sep 2014 08:57:22 -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 0A4981A8778 for ; Wed, 3 Sep 2014 08:57:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B805CD9307; Wed, 3 Sep 2014 17:57:16 +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 iKLPF4fduSQk; Wed, 3 Sep 2014 17:57:16 +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 5577FD9304; Wed, 3 Sep 2014 17:57:16 +0200 (MEST) Message-ID: <54073A5B.20207@tik.ee.ethz.ch> Date: Wed, 03 Sep 2014 17:57:15 +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> <53FF4E3F.4060502@tik.ee.ethz.ch> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> In-Reply-To: <201408282005.s7SK5ke4004064@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/mwpCBv50rWjwyF1B4_mDxl3jU90 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, 03 Sep 2014 15:57:28 -0000 Hi again, On 28.08.2014 22:05, Bob Briscoe wrote: >>>>>>>>>> * 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? > > The main problem is saying 'not available *for* control packets'. But > just changing 'for' to '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, given this is an > example, so it can be specific. > * Nit: duplicated word (for e.g. for) and duplicated phrase (as ACK are > usually not 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 is (currently) available > e.g. in TCP if one endpoint has been receiving data but sending nothing > but pure ACKs (no user data) for some time. This is because pure ACKs do > not advance the sequence number, so the TCP endpoint receiving them > cannot reliably tell whether any have been lost due to congestion. Pure > TCP ACKs cannot be ECN-marked either [RFC3168]." Fine for me. Done. >>>> 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... > > I thought the earlier definition said that ConEx accounts for the size > of the IP header that contains the CDO and everything within it. Also, > there's the TCP header size on a pure ACK. Yes, especially when a network node accounts ConEx marks. But in the (TCP) sender we just don't care about the header bits for simplification. We are aware that all bits will be accounted but as we assume equal size packets that should be fine. > That's the basis on which I am assuming that pure ACKs are worth > counting. A pure ACK will count as 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 be hard for TCP to know > though. Yes, so how should I implement that? >> 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. > > Agreed (that this would affect tcp-mods, not destopt). > > What is 'this' that you aren't yet convinced by? 'this' is the fact that I need to changed something in the tcp mods document. I might remove the statement (if existent) that control packets should be not-ConEx capable but I would still like to recommend it because I believe it makes things overly complicated otherwise. The point is I believe that at the location in the (Linux) code where you implement the counting, you don't even have the information how large the pure ACK will be in the end... > > >>> 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...? > > I thought you were proposing that a TCP sender assumes all the packets > it sends are full-sized, even if they aren't. But I believe you have > said that is not what you proposed. No, when reducing the congestion counter(s) we use the actual number of payload bytes. We also use the real number of acknowledged bytes to increase the counter(s). We simply do not care about the header bytes at all assuming that on average all packets have the same size and therefor the number of (marked) header bytes (either ECN or ConEx) in total will be about right. >>>>>>>>>> ==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? > > I think this will get thrown back by the IESG if we say 'MUST be first'. > And I think 'SHOULD be first' is a doable implementation for ConEx-aware > nodes. That is sufficient for experimental. Any experiments where > general forwarding nodes access ConEx will already be reading a destopt > at every hop, which is not what was intended, but it would be doable > just for an experiment that wanted to prove ConEx has wider uses. I know that this might be a problem with IESG review, but... it's broken... > > Everyone involved in IPv6 knows that the attempt to design extensibility > into v6 failed. It won't be news to the IESG that we can't add an > extension that can be processed at every hop on the fast path. > > If a destopt is sufficient to prove ConEx useful, then implementers will > want to satisfy this demand. Then > * either there is even more pressure on the IETF to address this failing > in v6 (and maybe someone will), > * or ConEx has to continue with this destopt solution, just like > everyone else is finding hacks round this failing in v6. > > But don't ask me. Ask Suresh. Yes! Unfortunately he did not response until now. Maybe he is/was on holidays; will ping him again. >>>>> 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? > > * How to do ConEx when IPsec is also required (tunnel & transport modes, > and what to count). This may all be obvious now, but (IMO) it would still > be worth spelling out obvious things. > * How to use IPsec to protect the integrity of CDO. Okay, this is the text now: "Compatibility with use of IPsec In IPv6 there are two possible position of a Destination Option header, either before the Routing header or after the Encapsulating Security Payload (ESP) header. If the packet is encrypted using IPSec tunnel mode, the CDO MUST be placed in the destination option before the Routing header such that it does not get encrypted and can be read by immediate ConEx-aware nodes. Note as the Authentication Header (AH) also only protects fields after the AH header, the CDO is not authenticated in this case. In IPSec transport mode both destination option headers can be used, as the CDO is in both cases visible to the network. If the transport network can not be trusted, the Destination Option header after the ESP header SHOULD be used to ensure integrity of the ConEx information. If an attacker would be able to remove the ConEx marks, this could cause an audit device to penalize the respective connection, while the sender cannot easily detect that ConEx information is missing." Does this seem to be right now? >>>>>>> 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. " > > OK. Rather than implying that equipment has evolved conscious awareness, > a better formulation would be something like: > "..the configuration of the tunnel ingress and the ConEx nodes is > co-ordinated." > > Nits: > s/SHOULD not/SHOULD NOT/ > s/accounted/counted/ > (in English, accounted is not a transitive verb, it has to have 'for' > after it) > s/ingree/ingress/ > s/theses/these/ > Done. > We're getting there! Yes...! Mirja > 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 >>>>>> >>>>>> >>>>>>>>>> ==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 >> ------------------------------------------ > > ________________________________________________________________ > 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 Mon Sep 8 15:17:33 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FD41A03F2 for ; Mon, 8 Sep 2014 15:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 g-RcmroPHk2c for ; Mon, 8 Sep 2014 15:17:26 -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 641CD1A031F for ; Mon, 8 Sep 2014 15:17:25 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 8 Sep 2014 23:17:23 +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; Mon, 8 Sep 2014 23:17:22 +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; Mon, 8 Sep 2014 23:17:20 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.134.6]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s88MHFDj018480; Mon, 8 Sep 2014 23:17:15 +0100 Message-ID: <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 8 Sep 2014 23:17:13 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <54073A5B.20207@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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@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/TciQURLS3vgBl7xy-171DLpRSh0 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, 08 Sep 2014 22:17:31 -0000 Mirja, At 16:57 03/09/2014, Mirja K=FChlewind wrote: >Hi again, > > >On 28.08.2014 22:05, Bob Briscoe wrote: >>>>>>>>>>>* 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? >> >>The main problem is saying 'not available *for* control packets'. But >>just changing 'for' to '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, given this is an >>example, so it can be specific. >>* Nit: duplicated word (for e.g. for) and duplicated phrase (as ACK are >>usually not 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 is (currently) available >>e.g. in TCP if one endpoint has been receiving data but sending nothing >>but pure ACKs (no user data) for some time. This is because pure ACKs do >>not advance the sequence number, so the TCP endpoint receiving them >>cannot reliably tell whether any have been lost due to congestion. Pure >>TCP ACKs cannot be ECN-marked either [RFC3168]." > >Fine for me. Done. > > >>>>>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... >> >>I thought the earlier definition said that ConEx accounts for the size >>of the IP header that contains the CDO and everything within it. Also, >>there's the TCP header size on a pure ACK. > >Yes, especially when a network node accounts=20 >ConEx marks. But in the (TCP) sender we just=20 >don't care about the header bits for=20 >simplification. We are aware that all bits will=20 >be accounted but as we assume equal size packets that should be fine. > > >>That's the basis on which I am assuming that pure ACKs are worth >>counting. A pure ACK will count as 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 be hard for TCP to know >>though. > >Yes, so how should I implement that? I guess just assume that any IP extensions will=20 be constant on every packet in a flow, therefore=20 assuming none will be similar to assuming some. >>>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. >> >>Agreed (that this would affect tcp-mods, not destopt). >> >>What is 'this' that you aren't yet convinced by? > >'this' is the fact that I need to changed=20 >something in the tcp mods document. I might=20 >remove the statement (if existent) that control=20 >packets should be not-ConEx capable but I would=20 >still like to recommend it because I believe it=20 >makes things overly complicated otherwise. The=20 >point is I believe that at the location in the=20 >(Linux) code where you implement the counting,=20 >you don't even have the information how large=20 >the pure ACK will be in the end... See next comment. >>>>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...? >> >>I thought you were proposing that a TCP sender assumes all the packets >>it sends are full-sized, even if they aren't. But I believe you have >>said that is not what you proposed. > >No, when reducing the congestion counter(s) we=20 >use the actual number of payload bytes. We also=20 >use the real number of acknowledged bytes to=20 >increase the counter(s). We simply do not care=20 >about the header bytes at all assuming that on=20 >average all packets have the same size and=20 >therefor the number of (marked) header bytes=20 >(either ECN or ConEx) in total will be about right. OK. I understand now. Ultimately TCP has to put a number in the Data=20 Offset field, so it has to know the size of its=20 own header. However, for an initial=20 (experimental) implementation, if you need your=20 proposal to assume all TCP options within one=20 flow are the same size, it would be reasonable=20 (it's not actually true, e.g. SACK, but there=20 should at least be no bias, so you will overstate as much as understate). You say earlier that it is too complicated to=20 implement code within TCP that knows the size of=20 a pure ACK. If TCP code doesn't know the size of=20 a TCP header, then Linux must be using magic=20 instead of code. Because, surely, the whole point=20 of the TCP code is to write a TCP header. >>>>>>>>>>>=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. traffic management or >>>multipath routing where 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 we say 'MUST be first'. >>And I think 'SHOULD be first' is a doable implementation for ConEx-aware >>nodes. That is sufficient for experimental. Any experiments where >>general forwarding nodes access ConEx will already be reading a destopt >>at every hop, which is not what was intended, but it would be doable >>just for an experiment that wanted to prove ConEx has wider uses. > >I know that this might be a problem with IESG review, but... it's broken... > >> >>Everyone involved in IPv6 knows that the attempt to design extensibility >>into v6 failed. It won't be news to the IESG that we can't add an >>extension that can be processed at every hop on the fast path. >> >>If a destopt is sufficient to prove ConEx useful, then implementers will >>want to satisfy this demand. Then >>* either there is even more pressure on the IETF to address this failing >>in v6 (and maybe someone will), >>* or ConEx has to continue with this destopt solution, just like >>everyone else is finding hacks round this failing in v6. >> >>But don't ask me. Ask Suresh. >Yes! Unfortunately he did not response until=20 >now. Maybe he is/was on holidays; will ping him again. > > >>>>>>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? > > >>* How to do ConEx when IPsec is also required (tunnel & transport modes, >>and what to count). This may all be obvious now, but (IMO) it would still > > be worth spelling out obvious things. >>* How to use IPsec to protect the integrity of CDO. > >Okay, this is the text now: > >"Compatibility with use of IPsec > >In IPv6 there are two possible position of a=20 >Destination Option header, either before the=20 >Routing header or after the Encapsulating Security Payload (ESP) header. BETTER?: In IPv6 a Destination Option header can be placed=20 in two possible position in the order of possible=20 headers, either before the Routing header or=20 after the Encapsulating Security Payload (ESP) header. REASONING: We are talking about the positions where these=20 headers /would/ be if they were there - they might not actually be present. >If the packet is encrypted using IPSec tunnel=20 >mode, the CDO MUST be placed in the destination=20 >option before the Routing header such that it=20 >does not get encrypted and can be read by immediate ConEx-aware nodes. BETTER?: CDO MUST always be placed in a destination option=20 header placed before where the routing header=20 would be. Otherwise, if CDO were placed in the=20 latter position and an ESP header were used, the CDO would be encrypt the REASONING: (There is no need for it to ever be in the later=20 position and it's best to always be in the same place.) >Note as the Authentication Header (AH) also only=20 >protects fields after the AH header, the CDO is not authenticated in this= case. Need to say the encapsulator copies CDO from the=20 inner IPv6 CDO before encrypting the inner. s/read by immediate/read by/ AH integrity protects the IPv6 header that encapsulates it. ESP does not. >In IPSec transport mode both destination option=20 >headers can be used, as the CDO is in both cases=20 >visible to the network. If the transport network=20 >can not be trusted, the Destination Option=20 >header after the ESP header SHOULD be used to=20 >ensure integrity of the ConEx information. If an=20 >attacker would be able to remove the ConEx=20 >marks, this could cause an audit device=20 >to penalize the respective connection, while the=20 >sender cannot easily detect that ConEx information is missing." > >Does this seem to be right now? Sorry, this is all wrong. One cannot use ESP to=20 authenticate or protect the integrity of CDO by=20 putting CDO after ESP, because ESP would then=20 encrypt CDO so ConEx-aware nodes would not be=20 able to read it. CDO always has to precede ESP,=20 which is why I said CDO MUST always be in the first destopt position. If the CDO header needs to be authenticated, AH=20 can be used as in the second example below. AH=20 protects the integrity of the whole IPv6 datagram=20 it is encapsulated by (except non-predictable=20 mutable fields). AH coverage includes the IPv6=20 header and extension headers before the AH=20 header, and everything after the AH header too. I think it would be worth listing the two or=20 three example header sequences in the draft, as=20 below. Headers in [] need not be present. Headers in {} are encrypted. Transport mode without the integrity of CDO protected: IPv6 [Hop-by-Hop] [Routing] Destopt(CDO[,...]) [Fragment] ESP{ [Destopt] Upper-Layer } Transport mode with the integrity of CDO protected: IPv6 [Hop-by-Hop] [Routing] Destopt(CDO[,...]) [Fragment] AH ESP{ [Destopt] Upper-Layer } Tunnel mode: IPv6 [Hop-by-Hop] [Routing] Destopt(CDO-copy[,...]) [Fragment] ESP{ IPv6 Destopt(CDO[,...]) Transport Payload } For ESP in tunnel mode, as already stated in the=20 draft, the tunnel ingress MUST copy the CDO from=20 the destopt in the inner, then write a copy of=20 the CDO header into a destopt header in the outer. I think this updates RFC2406. However, it is=20 possible that 2406 already requires an ESP=20 ingress to copy any extension headers, up to and=20 including Fragmentation, to the outer. Because=20 all these headers are designed to be visible to=20 nodes on the path. Suresh may know this. To protect the integrity of the outer IPv6=20 datagram, including protecting the copy of CDO,=20 an AH header (not shown) could be added before ESP. [A worse alternative (no need to mention this):=20 If the integrity of CDO but not other headers=20 needed to be protected, ESP with authentication=20 enabled could be used, which causes=20 authentication data to be added at the end of the=20 payload (not shown). Then, before decapsulation,=20 the tunnel egress would have to record the value=20 of CDO-copy. Having decrypted the inner, it could=20 then check that CDO-copy matched the CDO in the=20 inner. However, that would require another=20 update to RFC2406, so using AH would be=20 preferable, given we don't want to make ConEx=20 depend on updating both ends of an ESP tunnel - one end is bad enough.] HTH Sorry for taking so long - I wrote most of this=20 on a plane on Thu, but left some fact checking=20 for when I got online, and this is the first chance I've had to get back to= it. Cheers Bob >>>>>>>>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. " >> >>OK. Rather than implying that equipment has evolved conscious awareness, >>a better formulation would be something like: >>"..the configuration of the tunnel ingress and the ConEx nodes is >>co-ordinated." >> >>Nits: >>s/SHOULD not/SHOULD NOT/ >>s/accounted/counted/ >> (in English, accounted is not a transitive verb, it has to have 'for' >>after it) >>s/ingree/ingress/ >>s/theses/these/ > >Done. > > >>We're getting there! >Yes...! > >Mirja > > >>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 > >-- >------------------------------------------ >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 Sep 8 21:36: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 597651A0352 for ; Mon, 8 Sep 2014 21:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2J7uxoBGZGU for ; Mon, 8 Sep 2014 21:36:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D82F1A02F3 for ; Mon, 8 Sep 2014 21:36:02 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-d0-540e2bddf881 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 34.D2.25146.DDB2E045; Tue, 9 Sep 2014 00:21:17 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 00:36:01 -0400 From: Suresh Krishnan To: Bob Briscoe , =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: Act bits and Positioning (Was Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06) Thread-Index: AQHPy+eOOiAYG4y3CE6mb9CQHrSnSw== Date: Tue, 9 Sep 2014 04:36:00 +0000 Message-ID: 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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPuO5dbb4QgzX35S2mr//CaHHo2k9G iw2rp7BYvJzZwubA4tH2ZTKTx5IlP5k8nvzdwuxx7MNXtgCWKC6blNSczLLUIn27BK6MCZfK CrasZqp4v3wtewPjs4+MXYycHBICJhKfLj1jg7DFJC7cWw9kc3EICRxllFi8YDMThLOMUeL4 0m1gVWxAHRt2fmYCsUUEciS+Lz/BDmIzCzhJPJl4kxXEFhaIk7h05zMLRE2yxLyF16Dq9SR2 rrsEtplFQEXiVec8sBpeAV+JD4s3M0Is28oi8XQzxDJGoJO+n1rDBLFAXOLWk/lMEKcKSCzZ c54ZwhaVePn4HyuErSTx8fd8qIP0JG5MncIGYWtLLFv4mhlimaDEyZlPWCYwis5CMnYWkpZZ SFpmIWlZwMiyipGjtDi1LDfdyHATIzB2jkmwOe5gXPDJ8hCjAAejEg/vAzW+ECHWxLLiytxD jNIcLErivJrV84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MO7Rqd66ztHmh5PZaWu7hwfi rB0LBN64PWKsCHj57PelhZtq1i0XXHLl2NOdpcJdRrUhy08r7Fb6KLvKPqguZ+eiOc9eB8zc FLdna92kJt6Ut84nrjxfOcnwWPykJ1tbH1ucW3v2zzdx/blqruWu9n0yE96m3FX0qJfdfynH 9Oe+Pb/nx/8LTvRSYinOSDTUYi4qTgQAhGbVTH4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/conex/YKEa0Q-t2pCMcdGOf9GTlnnAk00 Cc: Carlos Ucendo , ConEx IETF list Subject: [conex] Act bits and Positioning (Was Re: 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, 09 Sep 2014 04:36:08 -0000 Hi Bob,=0A= Thanks a lot for your comments. I will respond to two specific issues=0A= that you brought up=0A= =0A= act bits being 01: Please note that the Conex option is a *destination*=0A= option. Non conex-aware nodes on path will not even process the option.=0A= So we do not need to be worried about the packet being dropped by=0A= intermediate nodes, and we need to know if the destination does not=0A= understand it. Hence I think this should stay as 01.=0A= =0A= CDO as the first option: As you rightly note, this is just a performance=0A= optimization. I do believe that the performance penalty for conex-aware=0A= nodes will be pretty severe if they need to process all destination=0A= options before deciding if the CDO is present or not. Please note that=0A= this needs to be done on *all* packets passing through the conex aware=0A= node. I do think it is OK to change the MUST to a SHOULD but with a=0A= severe warning.=0A= =0A= Cheers=0A= Suresh=0A= =0A= On 09/08/2014 06:17 PM, Bob Briscoe wrote:=0A= > Mirja,=0A= >=0A= > At 16:57 03/09/2014, Mirja K=FChlewind wrote:=0A= >> Hi again,=0A= >>=0A= >>=0A= >> On 28.08.2014 22:05, Bob Briscoe wrote:=0A= >>>>>>>>>>>> * Suggested deleting example of Not-ConEx-capable packets (see= =0A= >>>>>>>>>>>> separate thread to conex-tcp-modifications authors about TCP p= ure=0A= >>>>>>>>>>>> ACKs).=0A= >>>>>>>>>>> I can remove the example but not sure why you are suggesting=0A= >>>>>>>>>>> this. If=0A= >>>>>>>>>>> you actually imply that the X bit should never be zero that we= =0A= >>>>>>>>>>> have to=0A= >>>>>>>>>>> discuss if the X bit is needed at all.=0A= >>>>>>>>>> I have never thought the X flag was needed. There's probably som= e=0A= >>>>>>>>>> email=0A= >>>>>>>>>> on the list somewhere in the past from me that says that.=0A= >>>>>>>>>>=0A= >>>>>>>>>> As I put in one of the comment bubbles:=0A= >>>>>>>>>> "The only need I can see for the X-flag is if=0A= >>>>>>>>>> the Reserved field gets used in future for=0A= >>>>>>>>>> something in addition to ConEx. Then there=0A= >>>>>>>>>> would be a need to identify packets that=0A= >>>>>>>>>> are not ConEx-capable but still carry the=0A= >>>>>>>>>> CDO option (for the new reason)."=0A= >>>>>>>>>>=0A= >>>>>>>>>> Can anyone think of a use for the X flag?=0A= >>>>>>>>> I thought the X bit unset means: I'm a ConEx aware sender and i= =0A= >>>>>>>>> want to=0A= >>>>>>>>> follow the rules but I don't have any feedback for this (control)= =0A= >>>>>>>>> data=0A= >>>>>>>>> so I'm unable to give you useful ConEx information and if you use= =0A= >>>>>>>>> this=0A= >>>>>>>>> packet for your estimation of the current congestion level, you= =0A= >>>>>>>>> might=0A= >>>>>>>>> underestimate it.=0A= >>>>>>>>>=0A= >>>>>>>>> Doesn't that make sense...?=0A= >>>>>>> Not to me. What does "feedback for this (control) data" mean? Feedb= ack=0A= >>>>>>> is about a path used by a 5-tuple. This control data is about to be= =0A= >>>>>>> sent=0A= >>>>>>> over such a path. If the sender has feedback about that path, the= =0A= >>>>>>> feedback applies to everything sent over the path, at the IP layer,= =0A= >>>>>>> whatever categorisation the next packet has at L4.=0A= >>>>>> If you do not get any feedback on a path, e.g. a receiver only sendi= ng=0A= >>>>>> ACKs, you will never be able to send any ConEx markings. So what's t= he=0A= >>>>>> point about marking a packet as ConEx-enabled?=0A= >>>>> OK, this is a good example for when a ConEx-enabled flag might be=0A= >>>>> useful. However,...=0A= >>>>>=0A= >>>>> ...This doesn't justify marking pure ACKs as not-ConEx-enabled. If a= =0A= >>>>> sender sends a pure ACK now, all it knows is that it might not have= =0A= >>>>> enough feedback to be able to set ConEx markings on a whole sequence = of=0A= >>>>> packets later in the flow,... but only if it keeps sending solely pur= e=0A= >>>>> ACKs from now on. However, a sender can't be sure that it won't have= =0A= >>>>> enough feedback in future, because usually an app (let alone the=0A= >>>>> transport layer) cannot predict whether there will be more data to se= nd=0A= >>>>> later, even if it's not sending any now.=0A= >>>>>=0A= >>>>> Once a sender has had no feedback for at least a round trip, it has 2= =0A= >>>>> options for subsequent packets:=0A= >>>>> a) turn off ConEx-enabled;=0A= >>>>> b) keep sending packets with ConEx-enabled set, but conservatively ad= d=0A= >>>>> some credit.=0A= >>>>>=0A= >>>>> Even if it subsequently sends some data, it will still have to do (a)= or=0A= >>>>> (b) on these data packets, at least for one further round trip, until= it=0A= >>>>> gets the feedback. So this is nothing to do with whether the packet= =0A= >>>>> being sent is a pure ACK. It is to do with whether feedback has recen= tly=0A= >>>>> been received.=0A= >>>> Okay, rewrote the paragraph slightly:=0A= >>>>=0A= >>>> "If the X bit is zero all other three bits are undefined and thus=0A= >>>> should be ignored and forwarded unchanged by network nodes. The X bit= =0A= >>>> set to zero means that the connection is ConEx-capable but this packet= =0A= >>>> MUST NOT be accounted when determining ConEx information in an audit= =0A= >>>> function. This can be the case if no feedback on the congestion status= =0A= >>>> is (currently) available for e.g. for control packets (not carrying=0A= >>>> any user data). As an example a TCP receiver that only sends pure ACKs= =0A= >>>> will usually send them as ACK are usually not ECN-capable as ACK=0A= >>>> usually are not ECN-capable and TCP does not have a mechanism to=0A= >>>> announce ACK lost. Thus congestion information about ACKs are not=0A= >>>> available."=0A= >>>>=0A= >>>> Is this okay?=0A= >>> The main problem is saying 'not available *for* control packets'. But= =0A= >>> just changing 'for' to 'from' would still make this too unclear to be= =0A= >>> understood.=0A= >>>=0A= >>> Also need to:=0A= >>> * Make it clear the example is TCP-specific.=0A= >>> * Focus on loss first, then ECN.=0A= >>> * 'mechanism to announce ACK loss' is not really understandable.=0A= >>> * Avoid 'control packets', which is too general, given this is an=0A= >>> example, so it can be specific.=0A= >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as ACK are= =0A= >>> usually not ECN-capable as ACK usually are not ECN-capable).=0A= >>>=0A= >>> How about:=0A= >>>=0A= >>> First 2 sentences unchanged, then...=0A= >>> "This can be the case if no congestion feedback is (currently) availabl= e=0A= >>> e.g. in TCP if one endpoint has been receiving data but sending nothing= =0A= >>> but pure ACKs (no user data) for some time. This is because pure ACKs d= o=0A= >>> not advance the sequence number, so the TCP endpoint receiving them=0A= >>> cannot reliably tell whether any have been lost due to congestion. Pure= =0A= >>> TCP ACKs cannot be ECN-marked either [RFC3168]."=0A= >> Fine for me. Done.=0A= >>=0A= >>=0A= >>>>>> Further note, in the TCP mods we only look at the payload because we= =0A= >>>>>> assume, for simplification, all packets have the same size. Therefor= e=0A= >>>>>> a packet that carries no data would not decrease the CEG/LEG. If ACK= s=0A= >>>>>> should get marked, we need to rewrite all this stuff in the tcp mods= =0A= >>>>>> doc...=0A= >>>>> I don't think we should avoid changing tcp-mods if its 'not right'.= =0A= >>>>>=0A= >>>>> I hope you see the problem from my explanation above - whether there = is=0A= >>>>> enough feedback /now/ to ConEx-mark a packet has nothing to do with= =0A= >>>>> whether the packet being sent /now/ is capable of generating feedback= =0A= >>>>> /in the next round/.=0A= >>>>>=0A= >>>>> If you want to make a simplifying assumption, it is on the safe side = for=0A= >>>>> a sender to assume that all incoming feedback is about packets of the= =0A= >>>>> same size. It's not safe for a sender to assume that all packets it i= s=0A= >>>>> sending are the same size. Anyway, it knows what size it is sending, = so=0A= >>>>> it doesn't need this simplification.=0A= >>>> Okay, the assumption is (only) that feedback is based on packets that= =0A= >>>> are the same size. If we send you a packet we of course decrease the= =0A= >>>> LEG/CEG by the actually payload bytes. But taking this assumption be= =0A= >>>> simply do not account for headers at all (nor incoming neither=0A= >>>> outcoming) because we can anyway just estimated the header bits and=0A= >>>> there simply assume it will equal out. Which mean if we send a pure=0A= >>>> ACK we will not decrease the LEG/CEG because there are no payload=0A= >>>> bytes. I believe that this simplification makes thing much simpler and= =0A= >>>> is therefore useful but will not allow for marking pure ACKs...=0A= >>> I thought the earlier definition said that ConEx accounts for the size= =0A= >>> of the IP header that contains the CDO and everything within it. Also,= =0A= >>> there's the TCP header size on a pure ACK.=0A= >> Yes, especially when a network node accounts =0A= >> ConEx marks. But in the (TCP) sender we just =0A= >> don't care about the header bits for =0A= >> simplification. We are aware that all bits will =0A= >> be accounted but as we assume equal size packets that should be fine.=0A= >>=0A= >>=0A= >>> That's the basis on which I am assuming that pure ACKs are worth=0A= >>> counting. A pure ACK will count as at least 86B (and more if there are= =0A= >>> additional TCP options or IP extensions).=0A= >>>=0A= >>> IPv6 header: 40B=0A= >>> CDO dest opt: 6B=0A= >>> TCP header: 40B=0A= >>> Total: 86B=0A= >>>=0A= >>> If there are more IP extensions, I guess it will be hard for TCP to kno= w=0A= >>> though.=0A= >> Yes, so how should I implement that?=0A= > I guess just assume that any IP extensions will =0A= > be constant on every packet in a flow, therefore =0A= > assuming none will be similar to assuming some.=0A= >=0A= >>>> You didn't convince me (yet) that this should be changed but this=0A= >>>> would need to be changed in the tcp mods doc and not this one anyway.= =0A= >>> Agreed (that this would affect tcp-mods, not destopt).=0A= >>>=0A= >>> What is 'this' that you aren't yet convinced by?=0A= >> 'this' is the fact that I need to changed =0A= >> something in the tcp mods document. I might =0A= >> remove the statement (if existent) that control =0A= >> packets should be not-ConEx capable but I would =0A= >> still like to recommend it because I believe it =0A= >> makes things overly complicated otherwise. The =0A= >> point is I believe that at the location in the =0A= >> (Linux) code where you implement the counting, =0A= >> you don't even have the information how large =0A= >> the pure ACK will be in the end...=0A= > See next comment.=0A= >=0A= >>>>> The simplification I propose (that feedback is all about the same siz= e=0A= >>>>> packets, rather than all the sent packets are the same size) is likel= y=0A= >>>>> to be pretty good, given the receiver doesn't get loss or ECN info ab= out=0A= >>>>> pure ACKs, so they are automatically removed from the set of packets= =0A= >>>>> that the sender assumes to be the same size. And, and if some of the= =0A= >>>>> feedback is about smaller data packets, at least this simplification= =0A= >>>>> will always be on the safe side.=0A= >>>>>=0A= >>>>> If I correctly understand the simplification you propose, a ConEx sen= der=0A= >>>>> will more often under-declare congestion than over-declaring, which i= s=0A= >>>>> not safe.=0A= >>>> I don't believe so. Was this just of a different understanding of what= =0A= >>>> we proposed or can you explain further...?=0A= >>> I thought you were proposing that a TCP sender assumes all the packets= =0A= >>> it sends are full-sized, even if they aren't. But I believe you have=0A= >>> said that is not what you proposed.=0A= >> No, when reducing the congestion counter(s) we =0A= >> use the actual number of payload bytes. We also =0A= >> use the real number of acknowledged bytes to =0A= >> increase the counter(s). We simply do not care =0A= >> about the header bytes at all assuming that on =0A= >> average all packets have the same size and =0A= >> therefor the number of (marked) header bytes =0A= >> (either ECN or ConEx) in total will be about right.=0A= > OK. I understand now.=0A= >=0A= > Ultimately TCP has to put a number in the Data =0A= > Offset field, so it has to know the size of its =0A= > own header. However, for an initial =0A= > (experimental) implementation, if you need your =0A= > proposal to assume all TCP options within one =0A= > flow are the same size, it would be reasonable =0A= > (it's not actually true, e.g. SACK, but there =0A= > should at least be no bias, so you will overstate as much as understate).= =0A= >=0A= > You say earlier that it is too complicated to =0A= > implement code within TCP that knows the size of =0A= > a pure ACK. If TCP code doesn't know the size of =0A= > a TCP header, then Linux must be using magic =0A= > instead of code. Because, surely, the whole point =0A= > of the TCP code is to write a TCP header.=0A= >=0A= >>>>>>>>>>>> =3D=3DFast-path=3D=3D=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> * CDO as first destination option: changed from MUST to SHOULD= =0A= >>>>>>>>>>>> (with=0A= >>>>>>>>>>>> an example of when not to).=0A= >>>>>>>>>>> I believe this really needs to be a MUST. I know that might=0A= >>>>>>>>>>> restrict=0A= >>>>>>>>>>> the use of ConEx with potential other options that might have t= he=0A= >>>>>>>>>>> same=0A= >>>>>>>>>>> requirement (for different reasons). But if you don't put a MUS= T=0A= >>>>>>>>>>> here,=0A= >>>>>>>>>>> you cannot implemented the suggested way in the fast path.=0A= >>>>>>>>>> A SHOULD still means it will be the first option in all current= =0A= >>>>>>>>>> implementations. However, I suggest a SHOULD, precisely because= =0A= >>>>>>>>>> performance reasons are not absolute, so they don't require a=0A= >>>>>>>>>> MUST. If=0A= >>>>>>>>>> another dest opt cannot work at all unless it is first, that wou= ld=0A= >>>>>>>>>> be a=0A= >>>>>>>>>> valid reason for CDO coming second, because it still works, it's= =0A= >>>>>>>>>> /just/=0A= >>>>>>>>>> slower.=0A= >>>>>>>>>>=0A= >>>>>>>>>> The IESG will (rightly) be very wary of any draft that says an= =0A= >>>>>>>>>> option=0A= >>>>>>>>>> MUST be the first option.=0A= >>>>>>>>>>=0A= >>>>>>>>>> I suggested the following text after this: "(This is not=0A= >>>>>>>>>> stated as a 'MUST', because some future destination option might= =0A= >>>>>>>>>> need to=0A= >>>>>>>>>> be placed first for functional rather than just performance=0A= >>>>>>>>>> reasons.)"=0A= >>>>>>>>> So our fast path implementation must simply assume that there is = no=0A= >>>>>>>>> CDO=0A= >>>>>>>>> in case it cannot find it as the first option. Otherwise all=0A= >>>>>>>>> non-ConEx=0A= >>>>>>>>> packets would need to go to the slow path to make sure there is n= o=0A= >>>>>>>>> ConEx=0A= >>>>>>>>> option. That means to me that this must be a MUST...?=0A= >>>>>>> OK, I see the problem, but how much of a performance problem would = it=0A= >>>>>>> really be for the fast path of a ConEx function to step along dest= =0A= >>>>>>> opts=0A= >>>>>>> until it gets to CDO then stops (rather than stop if CDO is not=0A= >>>>>>> first)?=0A= >>>>>> So that's the different between you looking at one bit at a defined= =0A= >>>>>> position or having a chain of conditional look-ups where the length = is=0A= >>>>>> unknown. I believe that is something you would avoid to implement in= =0A= >>>>>> fast path as the processing time is not fixed anymore... that would = be=0A= >>>>>> my guess but I'm not an expert in this area.=0A= >>>>> AFAICT, fast path implementations generally work along sequences of= =0A= >>>>> extensions. So I don't think this is a problem. Bear in mind that we = are=0A= >>>>> not asking general fast path forwarding implementations to do this. O= nly=0A= >>>>> ConEx functions specifically written to find the ConEx header.{Note 1= }=0A= >>>>>=0A= >>>>> {Note 1} OK, we do suggest that general forwarding functions could do= =0A= >>>>> DoS protection using the ConEx header. But that's stated as optional = and=0A= >>>>> 'aspirational'. If such an experiment proves useful, you never know,= =0A= >>>>> there could be demand for ConEx to migrate into the hop-by-hop option= s=0A= >>>>> (according to the v6 spec, hop-by-hop and dest options share the same= =0A= >>>>> option number space, so this would be a straightforward migration, ju= st=0A= >>>>> moving where the CDO is placed, but using the same option number and= =0A= >>>>> format).=0A= >>>> There might be also further use cases for e.g. traffic management or= =0A= >>>> multipath routing where general forwarding nodes need to access this= =0A= >>>> information.=0A= >>>>=0A= >>>> So what's the solution here?=0A= >>> I think this will get thrown back by the IESG if we say 'MUST be first'= .=0A= >>> And I think 'SHOULD be first' is a doable implementation for ConEx-awar= e=0A= >>> nodes. That is sufficient for experimental. Any experiments where=0A= >>> general forwarding nodes access ConEx will already be reading a destopt= =0A= >>> at every hop, which is not what was intended, but it would be doable=0A= >>> just for an experiment that wanted to prove ConEx has wider uses.=0A= >> I know that this might be a problem with IESG review, but... it's broken= ...=0A= >>=0A= >>> Everyone involved in IPv6 knows that the attempt to design extensibilit= y=0A= >>> into v6 failed. It won't be news to the IESG that we can't add an=0A= >>> extension that can be processed at every hop on the fast path.=0A= >>>=0A= >>> If a destopt is sufficient to prove ConEx useful, then implementers wil= l=0A= >>> want to satisfy this demand. Then=0A= >>> * either there is even more pressure on the IETF to address this failin= g=0A= >>> in v6 (and maybe someone will),=0A= >>> * or ConEx has to continue with this destopt solution, just like=0A= >>> everyone else is finding hacks round this failing in v6.=0A= >>>=0A= >>> But don't ask me. Ask Suresh.=0A= >> Yes! Unfortunately he did not response until =0A= >> now. Maybe he is/was on holidays; will ping him again.=0A= >>=0A= >>=0A= >>>>>>> Then "CDO SHOULD be first" would give no different performance to "= CDO=0A= >>>>>>> MUST be first", if CDO actually was first. If CDO had to be placed= =0A= >>>>>>> second on a certain packet, "CDO SHOULD be first" would take just o= ne=0A= >>>>>>> more op than "CDO MUST be first".=0A= >>>>>>>=0A= >>>>>>> Note: I've just re-read the spec of the IPv6 header. We need to=0A= >>>>>>> specify=0A= >>>>>>> that CDO goes in the "Destination Options (before routing header)",= =0A= >>>>>>> not=0A= >>>>>>> the "Destination Options (before upper-layer header)". Then it=0A= >>>>>>> won't be=0A= >>>>>>> encrypted by an ESP header.=0A= >>>>>> Thanks. I wasn't fully aware of this. But the difference for my=0A= >>>>>> understanding is if immediate node listed in the routing header shou= ld=0A= >>>>>> proceed this option or not. In our case it is probably not important= =0A= >>>>>> which one we choose as it should be processed by none of the receive= rs.=0A= >>>>> You're correct that CDO isn't processed by any of the nodes listed in= =0A= >>>>> the routing header as destinations. The phrase "before routing header= "=0A= >>>>> is just how its placement is described. We should clarify that this= =0A= >>>>> isn't anything to do with the processing of the routing header.=0A= >>>>>=0A= >>>>>> Where did you read that the later one is not encrypted though?=0A= >>>>> ESP encrypts everything after the ESP header, and it comes just befor= e=0A= >>>>> the second dest opts. So it would be no good putting CDO after it.=0A= >>>>>=0A= >>>>> See the ESP spec, on "ESP Header Location":=0A= >>>>> =0A= >>>>> " The destination options extension header(s) could appear=0A= >>>>> either before or after the ESP header depending on the semantics= =0A= >>>>> desired. However, since ESP protects only fields after the ESP= =0A= >>>>> header, it generally may be desirable to place the destination=0A= >>>>> options header(s) after the ESP header.=0A= >>>>> "=0A= >>>> Thanks. Wasn't able to find this sentence!=0A= >>>>=0A= >>>>> Also see the IPv6 spec on "Extension Header Order":=0A= >>>>> =0A= >>>>>=0A= >>>>> I believe one reason there are two places for the dest opt is because= if=0A= >>>>> ESP is encrypting everything for the destination, it will normally be= =0A= >>>>> expected that the dest opts need to be encrypted too. But this wouldn= 't=0A= >>>>> work if you have multiple destinations on the path in the routing hea= der=0A= >>>>> (that probably don't hold the relevant key). Fortunately, this=0A= >>>>> exception is also needed for ConEx.=0A= >>>>>=0A= >>>>>> If so, I can simply add one sentence to the first paragraph of=0A= >>>>>> section 4:=0A= >>>>>> "The CDO MUST be placed in the destination option before routing=0A= >>>>>> header such that it does not get encrypted and can be read by=0A= >>>>>> immediate ConEx-aware nodes."=0A= >>>>>> And then remove the first paragraph of the IPSec section (and probab= ly=0A= >>>>>> move the other paragraph somewhere else so that the section is remov= ed=0A= >>>>>> completely)...?=0A= >>>>> I've lost track of all the proposed changes to the IPsec section. But= I=0A= >>>>> think there is value in spelling out exactly how ConEx and IPsec=0A= >>>>> interact, so I wouldn't remove the section completely, even if it=0A= >>>>> repeats info elsewhere.=0A= >>>> Okay I just realized that we recommend to to use TPSec for=0A= >>>> authentication but I believe if the ConEx option should not be=0A= >>>> encrypted by using the respective header, it will also not be=0A= >>>> authenticated...? So you can have either one of the two...? I believe= =0A= >>>> we still need the IPSec section but right now I'm not sure what to=0A= >>>> right in there...? Any proposal?=0A= >>> * How to do ConEx when IPsec is also required (tunnel & transport modes= ,=0A= >>> and what to count). This may all be obvious now, but (IMO) it would sti= ll=0A= >>> be worth spelling out obvious things.=0A= >>> * How to use IPsec to protect the integrity of CDO.=0A= >> Okay, this is the text now:=0A= >>=0A= >> "Compatibility with use of IPsec=0A= >>=0A= >> In IPv6 there are two possible position of a =0A= >> Destination Option header, either before the =0A= >> Routing header or after the Encapsulating Security Payload (ESP) header.= =0A= > BETTER?:=0A= > In IPv6 a Destination Option header can be placed =0A= > in two possible position in the order of possible =0A= > headers, either before the Routing header or =0A= > after the Encapsulating Security Payload (ESP) header.=0A= > REASONING:=0A= > We are talking about the positions where these =0A= > headers /would/ be if they were there - they might not actually be presen= t.=0A= >=0A= >> If the packet is encrypted using IPSec tunnel =0A= >> mode, the CDO MUST be placed in the destination =0A= >> option before the Routing header such that it =0A= >> does not get encrypted and can be read by immediate ConEx-aware nodes.= =0A= > BETTER?:=0A= > CDO MUST always be placed in a destination option =0A= > header placed before where the routing header =0A= > would be. Otherwise, if CDO were placed in the =0A= > latter position and an ESP header were used, the CDO would be encrypt the= =0A= > REASONING:=0A= > (There is no need for it to ever be in the later =0A= > position and it's best to always be in the same place.)=0A= >=0A= >=0A= >> Note as the Authentication Header (AH) also only =0A= >> protects fields after the AH header, the CDO is not authenticated in thi= s case.=0A= > Need to say the encapsulator copies CDO from the =0A= > inner IPv6 CDO before encrypting the inner.=0A= >=0A= > s/read by immediate/read by/=0A= >=0A= > AH integrity protects the IPv6 header that encapsulates it. ESP does not.= =0A= >=0A= >=0A= >> In IPSec transport mode both destination option =0A= >> headers can be used, as the CDO is in both cases =0A= >> visible to the network. If the transport network =0A= >> can not be trusted, the Destination Option =0A= >> header after the ESP header SHOULD be used to =0A= >> ensure integrity of the ConEx information. If an =0A= >> attacker would be able to remove the ConEx =0A= >> marks, this could cause an audit device =0A= >> to penalize the respective connection, while the =0A= >> sender cannot easily detect that ConEx information is missing."=0A= >>=0A= >> Does this seem to be right now?=0A= > Sorry, this is all wrong. One cannot use ESP to =0A= > authenticate or protect the integrity of CDO by =0A= > putting CDO after ESP, because ESP would then =0A= > encrypt CDO so ConEx-aware nodes would not be =0A= > able to read it. CDO always has to precede ESP, =0A= > which is why I said CDO MUST always be in the first destopt position.=0A= >=0A= > If the CDO header needs to be authenticated, AH =0A= > can be used as in the second example below. AH =0A= > protects the integrity of the whole IPv6 datagram =0A= > it is encapsulated by (except non-predictable =0A= > mutable fields). AH coverage includes the IPv6 =0A= > header and extension headers before the AH =0A= > header, and everything after the AH header too.=0A= >=0A= > I think it would be worth listing the two or =0A= > three example header sequences in the draft, as =0A= > below. Headers in [] need not be present. Headers in {} are encrypted.=0A= >=0A= > Transport mode without the integrity of CDO protected:=0A= > IPv6=0A= > [Hop-by-Hop]=0A= > [Routing]=0A= > Destopt(CDO[,...])=0A= > [Fragment]=0A= > ESP{=0A= > [Destopt]=0A= > Upper-Layer=0A= > }=0A= >=0A= > Transport mode with the integrity of CDO protected:=0A= > IPv6=0A= > [Hop-by-Hop]=0A= > [Routing]=0A= > Destopt(CDO[,...])=0A= > [Fragment]=0A= > AH=0A= > ESP{=0A= > [Destopt]=0A= > Upper-Layer=0A= > }=0A= >=0A= >=0A= > Tunnel mode:=0A= > IPv6=0A= > [Hop-by-Hop]=0A= > [Routing]=0A= > Destopt(CDO-copy[,...])=0A= > [Fragment]=0A= > ESP{=0A= > IPv6=0A= > Destopt(CDO[,...])=0A= > Transport Payload=0A= > }=0A= >=0A= > For ESP in tunnel mode, as already stated in the =0A= > draft, the tunnel ingress MUST copy the CDO from =0A= > the destopt in the inner, then write a copy of =0A= > the CDO header into a destopt header in the outer.=0A= >=0A= > I think this updates RFC2406. However, it is =0A= > possible that 2406 already requires an ESP =0A= > ingress to copy any extension headers, up to and =0A= > including Fragmentation, to the outer. Because =0A= > all these headers are designed to be visible to =0A= > nodes on the path. Suresh may know this.=0A= >=0A= > To protect the integrity of the outer IPv6 =0A= > datagram, including protecting the copy of CDO, =0A= > an AH header (not shown) could be added before ESP.=0A= >=0A= > [A worse alternative (no need to mention this): =0A= > If the integrity of CDO but not other headers =0A= > needed to be protected, ESP with authentication =0A= > enabled could be used, which causes =0A= > authentication data to be added at the end of the =0A= > payload (not shown). Then, before decapsulation, =0A= > the tunnel egress would have to record the value =0A= > of CDO-copy. Having decrypted the inner, it could =0A= > then check that CDO-copy matched the CDO in the =0A= > inner. However, that would require another =0A= > update to RFC2406, so using AH would be =0A= > preferable, given we don't want to make ConEx =0A= > depend on updating both ends of an ESP tunnel - one end is bad enough.]= =0A= >=0A= > HTH=0A= > Sorry for taking so long - I wrote most of this =0A= > on a plane on Thu, but left some fact checking =0A= > for when I got online, and this is the first chance I've had to get back = to it.=0A= >=0A= > Cheers=0A= >=0A= >=0A= >=0A= > Bob=0A= >=0A= >>>>>>>>> Moreover, isn't this here the same case than with tunneling in=0A= >>>>>>>>> general.=0A= >>>>>>>>> Only if the node that does the encapsulation is ConEx-aware it ca= n=0A= >>>>>>>>> copy=0A= >>>>>>>>> the CDO, otherwise it will be not visible anymore.=0A= >>>>>>>>>=0A= >>>>>>>>> So this should either be a should, or we have to say something=0A= >>>>>>>>> like: if=0A= >>>>>>>>> the node is ConEx-aware is MUST copy the CDO...?=0A= >>>>>>>> And then we can the same thing for tunneling in general...?=0A= >>>>>>> That's surely a circular argument. What would make a tunnel endpoin= t=0A= >>>>>>> into a ConEx-aware tunnel endpoint, so that it would have to copy t= he=0A= >>>>>>> CDO? It would only become ConEx-aware if it had code added to look = for=0A= >>>>>>> the CDO, and why would it have that code added unless it was going= =0A= >>>>>>> to do=0A= >>>>>>> something with CDO? That's why I think my 'MAY copy as a performanc= e=0A= >>>>>>> optimisation' formula is the best we can do.=0A= >>>>>> What you say above is the point. If the node does not know anything= =0A= >>>>>> about ConEx, it simple cannot copy the option, which is the case for= =0A= >>>>>> all currently existent nodes. So we cannot say MUST in general. But = if=0A= >>>>>> the node does know that ConEx exists for any reason, it really must= =0A= >>>>>> copy the CDO...? But you right that is a little pathologic. I'm will= =0A= >>>>>> to change if that helps understanding/is less confusing.=0A= >>>>> I think we're talking past each other. Given we cannot copy CDO to th= e=0A= >>>>> outer everywhere, for consistency I don't think that copying CDO to t= he=0A= >>>>> outer at all is a good idea, UNLESS it's done deliberately as part of= an=0A= >>>>> operator's whole approach to handling ConEx. Ie. tunnel endpoints SHO= ULD=0A= >>>>> NOT copy CDO to the outer by default, but they MAY copy CDO to the ou= ter=0A= >>>>> for a specific purpose (e.g. optimisation for ConEx functions elsewhe= re=0A= >>>>> in the same operator's network).=0A= >>>> Now understood.=0A= >>>>=0A= >>>> I've tried to make this point a little more clear, not sure if I=0A= >>>> succeeded:=0A= >>>> "As with any destination option, an ingress tunnel endpoint will not= =0A= >>>> natively copy the CDO when adding an encapsulating outer IP header. In= =0A= >>>> general an ingress tunnel SHOULD not copy the CDO to the outer header= =0A= >>>> as this would changed the number of bytes that would be accounted.=0A= >>>> However, it MAY copy the CDO to the outer in order to facilitate=0A= >>>> visibility by subsequent on-path ConEx functions if the tunnel ingree= =0A= >>>> is aware of these nodes and theses nodes are aware of the tunneling.= =0A= >>>> This trades off the performance of ConEx functions against that of=0A= >>>> tunnel processing. "=0A= >>> OK. Rather than implying that equipment has evolved conscious awareness= ,=0A= >>> a better formulation would be something like:=0A= >>> "..the configuration of the tunnel ingress and the ConEx nodes is=0A= >>> co-ordinated."=0A= >>>=0A= >>> Nits:=0A= >>> s/SHOULD not/SHOULD NOT/=0A= >>> s/accounted/counted/=0A= >>> (in English, accounted is not a transitive verb, it has to have 'for= '=0A= >>> after it)=0A= >>> s/ingree/ingress/=0A= >>> s/theses/these/=0A= >> Done.=0A= >>=0A= >>=0A= >>> We're getting there!=0A= >> Yes...!=0A= >>=0A= >> Mirja=0A= >>=0A= >>=0A= >>> But we really do need Suresh's expert eye on this.=0A= >>>=0A= >>>=0A= >>> Cheers=0A= >>>=0A= >>>=0A= >>> Bob=0A= >>>=0A= >>>=0A= >>>> Mirja=0A= >>>>=0A= >>>>> HTH=0A= >>>>> (Delayed 'cos it was a public holday in the UK yesterday.)=0A= >>>>>=0A= >>>>>=0A= >>>>> Bob=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>>>> Bob=0A= >>>>>>>=0A= >>>>>>>=0A= >>>>>>>> Mirja=0A= >>>>>>>>=0A= >>>>>>>>=0A= >>>>>>>>>>>> =3D=3DSecurity Considerations=3D=3D=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> * Added lots, all pointers to where security issues are=0A= >>>>>>>>>>>> discussed in=0A= >>>>>>>>>>>> other places (which is what security directorate reviewers nee= d).=0A= >>>>>>>>>>> Okay I can add that if you think it's necessary (I would say it= 's=0A= >>>>>>>>>>> just=0A= >>>>>>>>>>> redundant, but you be might right that it just helps the sec di= r).=0A= >>>>>>>>>> It's not always obvious which aspects relate to security.=0A= >>>>>>>>>> Especially=0A= >>>>>>>>>> when the security is structural rather than crypto. So I think= =0A= >>>>>>>>>> these=0A= >>>>>>>>>> sentences are useful to sec dir.=0A= >>>>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>>>> =3D=3DIANA=3D=3D=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> * I think the act bits need to be 00 not 10 to avoid ConEx=0A= >>>>>>>>>>>> packets=0A= >>>>>>>>>>>> being dropped by non-ConEx nodes (including by non-ConEx=0A= >>>>>>>>>>>> receivers)?=0A= >>>>>>>>>>>> But I'm willing to be corrected.=0A= >>>>>>>>>>> I agree; Will ask Suresh why he has put a 10 though.=0A= >>>>>>>>>> Yes, he's the right guy to check with.=0A= >>>>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>> Bob=0A= >>>>>>>>>>=0A= >>>>>>>>>>=0A= >>>>>>>>>>> Thanks,=0A= >>>>>>>>>>> Mirja=0A= >>>>>>>>>>>=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> Regards=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> Bob=0A= >>>>>>>>>> {Note 1}=0A= >>>>>>>>>> For anyone watching on the list, the tentative idea that Mirja h= as=0A= >>>>>>>>>> reminded me of is documented in 11.3.1 of my PhD thesis entitled= =0A= >>>>>>>>>> "Covert=0A= >>>>>>>>>> Markings as a Policer Signal".=0A= >>>>>>>>>>=0A= >>>>>>>>>> The potential problem: A ConEx policer punishes punishment. If a= =0A= >>>>>>>>>> congestion policer starts dropping packets because the user has= =0A= >>>>>>>>>> contributed excessively to congestion, in subsequent rounds the= =0A= >>>>>>>>>> user=0A= >>>>>>>>>> has=0A= >>>>>>>>>> to re-echo 'L' markings for the policer drops as well. This can= =0A= >>>>>>>>>> drive=0A= >>>>>>>>>> the policer further into 'debit'. This might make it difficult f= or=0A= >>>>>>>>>> the=0A= >>>>>>>>>> user to get out of trouble once she's started getting into troub= le.=0A= >>>>>>>>>>=0A= >>>>>>>>>> The basic idea was that when a congestion policer drops packets= =0A= >>>>>>>>>> (because=0A= >>>>>>>>>> the user is causing more congestion than her allowance), it will= =0A= >>>>>>>>>> also=0A= >>>>>>>>>> remove ConEx markings. Then (if there is some way for the=0A= >>>>>>>>>> receiver to=0A= >>>>>>>>>> feed this back), the sender knows not to send more ConEx marks= =0A= >>>>>>>>>> because=0A= >>>>>>>>>> these aren't congestion drops, they are policer drops.=0A= >>>>>>>>>>=0A= >>>>>>>>>> We didn't that double punishment made it hard to get out of=0A= >>>>>>>>>> trouble in=0A= >>>>>>>>>> any policer experiments so far, so let's not allow for a possibl= e=0A= >>>>>>>>>> solution to a problem that we probably don't even have. The curr= ent=0A= >>>>>>>>>> crop=0A= >>>>>>>>>> of ConEx drafts are experimental anyway. If this problem does=0A= >>>>>>>>>> surface,=0A= >>>>>>>>>> then we can reconsider.=0A= >>>>>>>>>> ________________________________________________________________= =0A= >>>>>>>>>> Bob Briscoe, BT= =0A= >>>>>>>> --=0A= >>>>>>>> ------------------------------------------=0A= >>>>>>>> Dipl.-Ing. Mirja K=FChlewind=0A= >>>>>>>> Communication Systems Group=0A= >>>>>>>> Institute TIK, ETH Z=FCrich=0A= >>>>>>>> Gloriastrasse 35, 8092 Z=FCrich, Switzerland=0A= >>>>>>>>=0A= >>>>>>>> Room ETZ G93=0A= >>>>>>>> phone: +41 44 63 26932=0A= >>>>>>>> email: mirja.kuehlewind@tik.ee.ethz.ch=0A= >>>>>>>> ------------------------------------------=0A= >>>>>>> ________________________________________________________________=0A= >>>>>>> Bob Briscoe, BT=0A= >>>>>> --=0A= >>>>>> ------------------------------------------=0A= >>>>>> Dipl.-Ing. Mirja K=FChlewind=0A= >>>>>> Communication Systems Group=0A= >>>>>> Institute TIK, ETH Z=FCrich=0A= >>>>>> Gloriastrasse 35, 8092 Z=FCrich, Switzerland=0A= >>>>>>=0A= >>>>>> Room ETZ G93=0A= >>>>>> phone: +41 44 63 26932=0A= >>>>>> email: mirja.kuehlewind@tik.ee.ethz.ch=0A= >>>>>> ------------------------------------------=0A= >>>>> ________________________________________________________________=0A= >>>>> Bob Briscoe, BT=0A= >>>> --=0A= >>>> ------------------------------------------=0A= >>>> Dipl.-Ing. Mirja K=FChlewind=0A= >>>> Communication Systems Group=0A= >>>> Institute TIK, ETH Z=FCrich=0A= >>>> Gloriastrasse 35, 8092 Z=FCrich, Switzerland=0A= >>>>=0A= >>>> Room ETZ G93=0A= >>>> phone: +41 44 63 26932=0A= >>>> email: mirja.kuehlewind@tik.ee.ethz.ch=0A= >>>> ------------------------------------------=0A= >>> ________________________________________________________________=0A= >>> Bob Briscoe, BT=0A= >> --=0A= >> ------------------------------------------=0A= >> Dipl.-Ing. Mirja K=FChlewind=0A= >> Communication Systems Group=0A= >> Institute TIK, ETH Z=FCrich=0A= >> Gloriastrasse 35, 8092 Z=FCrich, Switzerland=0A= >>=0A= >> Room ETZ G93=0A= >> phone: +41 44 63 26932=0A= >> email: mirja.kuehlewind@tik.ee.ethz.ch=0A= >> ------------------------------------------=0A= > ________________________________________________________________=0A= > Bob Briscoe, BT =0A= >=0A= >=0A= =0A= From nobody Tue Sep 9 01:00: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 0EC6C1A6EFB for ; Tue, 9 Sep 2014 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 y8iqSFie8Sba for ; Tue, 9 Sep 2014 01:00:06 -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 244431A6EF8 for ; Tue, 9 Sep 2014 01:00:04 -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; Tue, 9 Sep 2014 09:00:01 +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, 9 Sep 2014 09:00:00 +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, 9 Sep 2014 08:59:57 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.171.217]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s897xriV019964; Tue, 9 Sep 2014 08:59:53 +0100 Message-ID: <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 9 Sep 2014 08:59:52 +0100 To: Suresh Krishnan , Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: 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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/UBUzyRScojsDEYxawdS5TXaN9yo Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Act bits and Positioning (Was Re: 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, 09 Sep 2014 08:00:21 -0000 Suresh, At 05:36 09/09/2014, Suresh Krishnan wrote: >Hi Bob, > Thanks a lot for your comments. I will respond to two specific issues >that you brought up > >act bits being 01: Please note that the Conex option is a *destination* >option. Non conex-aware nodes on path will not even process the option. >So we do not need to be worried about the packet being dropped by >intermediate nodes, and we need to know if the destination does not >understand it. Hence I think this should stay as 01. I was aware that the act bits are only processed by the destination. My point was that ConEx only requires sender=20 support (ie. you can have ConEx on one=20 half-connection but not the other - there is no=20 need to negotiate ConEx for a connection). So it=20 would be very bad for a destination to drop a=20 packet just before delivering it to the=20 destination process just because it doesn't=20 recognise a ConEx header that it doesn't need to understand anyway. Note to Mirja: Given this misunderstanding,=20 perhaps the draft should give a reason: "The act bits MUST be 00, because a=20 ConEx packet needs to be passed to the=20 destination process even if the destination does not understand ConEx." >CDO as the first option: As you rightly note, this is just a performance >optimization. I do believe that the performance penalty for conex-aware >nodes will be pretty severe if they need to process all destination >options before deciding if the CDO is present or not. Surely a ConEx node can stop when it gets to the=20 CDO option (which will usually be first). It=20 doesn't need to continue and process all the=20 other options within the destopt header. >Please note that >this needs to be done on *all* packets passing through the conex aware >node. On packets without a destopt that is quick. The really bad case is for packets from senders=20 that don't support ConEx but are using many other=20 destopts. Then the on-path ConEx node would walk=20 along every destopt until the end. >I do think it is OK to change the MUST to a SHOULD but with a >severe warning. OK, thanks. Would it be OK to say "As an optimization, a=20 ConEx implementation MAY limit the depth of its=20 search for CDO to two or three destination options"? I have also added to my response to Mirja below,=20 with an extra thought about ESP tunnels (inline -=20 search for 'ESP tunnel' - it's a long way down!)... >Cheers >Suresh > >On 09/08/2014 06:17 PM, Bob Briscoe wrote: > > Mirja, > > > > At 16:57 03/09/2014, Mirja K=FChlewind wrote: > >> Hi again, > >> > >> > >> On 28.08.2014 22:05, Bob Briscoe wrote: > >>>>>>>>>>>> * Suggested deleting example of Not-ConEx-capable packets= (see > >>>>>>>>>>>> separate thread to=20 > 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=20 > (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,=20 > it will still have to do (a) or > >>>>> (b) on these data packets, at least for=20 > 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=20 > 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? > >>> The main problem is saying 'not available *for* control packets'. But > >>> just changing 'for' to '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, given this is an > >>> example, so it can be specific. > >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as ACK= are > >>> usually not 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 is (currently)= available > >>> e.g. in TCP if one endpoint has been receiving data but sending= nothing > >>> but pure ACKs (no user data) for some time. This is because pure ACKs= do > >>> not advance the sequence number, so the TCP endpoint receiving them > >>> cannot reliably tell whether any have been lost due to congestion.= Pure > >>> TCP ACKs cannot be ECN-marked either [RFC3168]." > >> Fine for me. Done. > >> > >> > >>>>>> 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=20 > 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... > >>> I thought the earlier definition said that ConEx accounts for the size > >>> of the IP header that contains the CDO and everything within it. Also, > >>> there's the TCP header size on a pure ACK. > >> Yes, especially when a network node accounts > >> ConEx marks. But in the (TCP) sender we just > >> don't care about the header bits for > >> simplification. We are aware that all bits will > >> be accounted but as we assume equal size packets that should be fine. > >> > >> > >>> That's the basis on which I am assuming that pure ACKs are worth > >>> counting. A pure ACK will count as 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 be hard for TCP to= know > >>> though. > >> Yes, so how should I implement that? > > I guess just assume that any IP extensions will > > be constant on every packet in a flow, therefore > > assuming none will be similar to assuming some. > > > >>>> 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. > >>> Agreed (that this would affect tcp-mods, not destopt). > >>> > >>> What is 'this' that you aren't yet convinced by? > >> 'this' is the fact that I need to changed > >> something in the tcp mods document. I might > >> remove the statement (if existent) that control > >> packets should be not-ConEx capable but I would > >> still like to recommend it because I believe it > >> makes things overly complicated otherwise. The > >> point is I believe that at the location in the > >> (Linux) code where you implement the counting, > >> you don't even have the information how large > >> the pure ACK will be in the end... > > See next comment. > > > >>>>> 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=20 > 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=20 > 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...? > >>> I thought you were proposing that a TCP sender assumes all the packets > >>> it sends are full-sized, even if they aren't. But I believe you have > >>> said that is not what you proposed. > >> No, when reducing the congestion counter(s) we > >> use the actual number of payload bytes. We also > >> use the real number of acknowledged bytes to > >> increase the counter(s). We simply do not care > >> about the header bytes at all assuming that on > >> average all packets have the same size and > >> therefor the number of (marked) header bytes > >> (either ECN or ConEx) in total will be about right. > > OK. I understand now. > > > > Ultimately TCP has to put a number in the Data > > Offset field, so it has to know the size of its > > own header. However, for an initial > > (experimental) implementation, if you need your > > proposal to assume all TCP options within one > > flow are the same size, it would be reasonable > > (it's not actually true, e.g. SACK, but there > > should at least be no bias, so you will overstate as much as= understate). > > > > You say earlier that it is too complicated to > > implement code within TCP that knows the size of > > a pure ACK. If TCP code doesn't know the size of > > a TCP header, then Linux must be using magic > > instead of code. Because, surely, the whole point > > of the TCP code is to write a TCP header. > > > >>>>>>>>>>>> =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=20 > problem. Bear in mind that we are > >>>>> not asking general fast path forwarding=20 > 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.=20 > 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? > >>> I think this will get thrown back by the IESG if we say 'MUST be= first'. > >>> And I think 'SHOULD be first' is a doable implementation for= ConEx-aware > >>> nodes. That is sufficient for experimental. Any experiments where > >>> general forwarding nodes access ConEx will already be reading a= destopt > >>> at every hop, which is not what was intended, but it would be doable > >>> just for an experiment that wanted to prove ConEx has wider uses. > >> I know that this might be a problem with=20 > IESG review, but... it's broken... > >> > >>> Everyone involved in IPv6 knows that the attempt to design= extensibility > >>> into v6 failed. It won't be news to the IESG that we can't add an > >>> extension that can be processed at every hop on the fast path. > >>> > >>> If a destopt is sufficient to prove ConEx useful, then implementers= will > >>> want to satisfy this demand. Then > >>> * either there is even more pressure on the IETF to address this= failing > >>> in v6 (and maybe someone will), > >>> * or ConEx has to continue with this destopt solution, just like > >>> everyone else is finding hacks round this failing in v6. > >>> > >>> But don't ask me. Ask Suresh. > >> Yes! Unfortunately he did not response until > >> now. Maybe he is/was on holidays; will ping him again. > >> > >> > >>>>>>> Then "CDO SHOULD be first" would give=20 > 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=20 > 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=20 > 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=20 > 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? > >>> * How to do ConEx when IPsec is also required (tunnel & transport= modes, > >>> and what to count). This may all be obvious now, but (IMO) it would= still > >>> be worth spelling out obvious things. > >>> * How to use IPsec to protect the integrity of CDO. > >> Okay, this is the text now: > >> > >> "Compatibility with use of IPsec > >> > >> In IPv6 there are two possible position of a > >> Destination Option header, either before the > >> Routing header or after the Encapsulating Security Payload (ESP)= header. > > BETTER?: > > In IPv6 a Destination Option header can be placed > > in two possible position in the order of possible > > headers, either before the Routing header or > > after the Encapsulating Security Payload (ESP) header. > > REASONING: > > We are talking about the positions where these > > headers /would/ be if they were there - they might not actually be= present. > > > >> If the packet is encrypted using IPSec tunnel > >> mode, the CDO MUST be placed in the destination > >> option before the Routing header such that it > >> does not get encrypted and can be read by immediate ConEx-aware nodes. > > BETTER?: > > CDO MUST always be placed in a destination option > > header placed before where the routing header > > would be. Otherwise, if CDO were placed in the > > latter position and an ESP header were used, the CDO would be encrypt= the > > REASONING: > > (There is no need for it to ever be in the later > > position and it's best to always be in the same place.) > > > > > >> Note as the Authentication Header (AH) also only > >> protects fields after the AH header, the CDO=20 > is not authenticated in this case. > > Need to say the encapsulator copies CDO from the > > inner IPv6 CDO before encrypting the inner. > > > > s/read by immediate/read by/ > > > > AH integrity protects the IPv6 header that encapsulates it. ESP does= not. > > > > > >> In IPSec transport mode both destination option > >> headers can be used, as the CDO is in both cases > >> visible to the network. If the transport network > >> can not be trusted, the Destination Option > >> header after the ESP header SHOULD be used to > >> ensure integrity of the ConEx information. If an > >> attacker would be able to remove the ConEx > >> marks, this could cause an audit device > >> to penalize the respective connection, while the > >> sender cannot easily detect that ConEx information is missing." > >> > >> Does this seem to be right now? > > Sorry, this is all wrong. One cannot use ESP to > > authenticate or protect the integrity of CDO by > > putting CDO after ESP, because ESP would then > > encrypt CDO so ConEx-aware nodes would not be > > able to read it. CDO always has to precede ESP, > > which is why I said CDO MUST always be in the first destopt position. > > > > If the CDO header needs to be authenticated, AH > > can be used as in the second example below. AH > > protects the integrity of the whole IPv6 datagram > > it is encapsulated by (except non-predictable > > mutable fields). AH coverage includes the IPv6 > > header and extension headers before the AH > > header, and everything after the AH header too. > > > > I think it would be worth listing the two or > > three example header sequences in the draft, as > > below. Headers in [] need not be present. Headers in {} are encrypted. > > > > Transport mode without the integrity of CDO protected: > > IPv6 > > [Hop-by-Hop] > > [Routing] > > Destopt(CDO[,...]) > > [Fragment] > > ESP{ > > [Destopt] > > Upper-Layer > > } > > > > Transport mode with the integrity of CDO protected: > > IPv6 > > [Hop-by-Hop] > > [Routing] > > Destopt(CDO[,...]) > > [Fragment] > > AH > > ESP{ > > [Destopt] > > Upper-Layer > > } > > > > > > Tunnel mode: > > IPv6 > > [Hop-by-Hop] > > [Routing] > > Destopt(CDO-copy[,...]) > > [Fragment] > > ESP{ > > IPv6 > > Destopt(CDO[,...]) > > Transport Payload > > } > > > > For ESP in tunnel mode, as already stated in the > > draft, the tunnel ingress MUST copy the CDO from > > the destopt in the inner, then write a copy of > > the CDO header into a destopt header in the outer. > > > > I think this updates RFC2406. However, it is > > possible that 2406 already requires an ESP > > ingress to copy any extension headers, up to and > > including Fragmentation, to the outer. Because > > all these headers are designed to be visible to > > nodes on the path. Suresh may know this. I checked overnight and copying extension headers=20 is contrary to the IPSec architecture. =20 "IPv6 -- Header Construction for Tunnel Mode" says: "Extension headers never copied" On reflection, I don't think we should update=20 RFC2401 for ConEx. If I were on the IESG, I would=20 not approve that. IPsec needs to have simple rules without exceptions. When we chose destopt as the mechanism for ConEx,=20 we knew it wasn't going to interact well with=20 tunnels. I think the best approach is to say, "Currently, the IPv6 protocol=20 architecture does not provide a mechanism for new=20 extension headers to be copied to the outer.=20 Therefore ConEx functions will have to search for=20 the CDO option within inner headers, and ConEx=20 will not work at all over the extent of an ESP tunnel". Bob > > > > To protect the integrity of the outer IPv6 > > datagram, including protecting the copy of CDO, > > an AH header (not shown) could be added before ESP. > > > > [A worse alternative (no need to mention this): > > If the integrity of CDO but not other headers > > needed to be protected, ESP with authentication > > enabled could be used, which causes > > authentication data to be added at the end of the > > payload (not shown). Then, before decapsulation, > > the tunnel egress would have to record the value > > of CDO-copy. Having decrypted the inner, it could > > then check that CDO-copy matched the CDO in the > > inner. However, that would require another > > update to RFC2406, so using AH would be > > preferable, given we don't want to make ConEx > > depend on updating both ends of an ESP tunnel - one end is bad enough.] > > > > HTH > > Sorry for taking so long - I wrote most of this > > on a plane on Thu, but left some fact checking > > for when I got online, and this is the first=20 > chance I've had to get back to it. > > > > Cheers > > > > > > > > Bob > > > >>>>>>>>> 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=20 > 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=20 > done deliberately as part of an > >>>>> operator's whole approach to handling=20 > ConEx. Ie. tunnel endpoints SHOULD > >>>>> NOT copy CDO to the outer by default, but=20 > 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. " > >>> OK. Rather than implying that equipment has evolved conscious= awareness, > >>> a better formulation would be something like: > >>> "..the configuration of the tunnel ingress and the ConEx nodes is > >>> co-ordinated." > >>> > >>> Nits: > >>> s/SHOULD not/SHOULD NOT/ > >>> s/accounted/counted/ > >>> (in English, accounted is not a transitive verb, it has to have= 'for' > >>> after it) > >>> s/ingree/ingress/ > >>> s/theses/these/ > >> Done. > >> > >> > >>> We're getting there! > >> Yes...! > >> > >> Mirja > >> > >> > >>> 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=20 > 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=20 > 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=20 > 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=20 > 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 > >> -- > >> ------------------------------------------ > >> 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 > > > > ________________________________________________________________ Bob Briscoe, BT=20 From nobody Tue Sep 9 07:19:55 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 9EA9F1A0BEA for ; Tue, 9 Sep 2014 07:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 H8e9wA9OFRCb for ; Tue, 9 Sep 2014 07:19:46 -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 5A52A1A6F9D for ; Tue, 9 Sep 2014 07:19:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6B463D930A; Tue, 9 Sep 2014 16:19: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 dQpJq25Ux-98; Tue, 9 Sep 2014 16:19:37 +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 05172D9304; Tue, 9 Sep 2014 16:19:37 +0200 (MEST) Message-ID: <540F0C78.7050309@tik.ee.ethz.ch> Date: Tue, 09 Sep 2014 16:19:36 +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 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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> In-Reply-To: <201409090759.s897xriV019964@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/NYC3ATzxlDqps29nj7fwoAcSCzw Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Act bits and Positioning (Was Re: 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, 09 Sep 2014 14:19:52 -0000 Hi, see inline On 09.09.2014 09:59, Bob Briscoe wrote: > Suresh, > > At 05:36 09/09/2014, Suresh Krishnan wrote: >> Hi Bob, >> Thanks a lot for your comments. I will respond to two specific issues >> that you brought up >> >> act bits being 01: Please note that the Conex option is a *destination* >> option. Non conex-aware nodes on path will not even process the option. >> So we do not need to be worried about the packet being dropped by >> intermediate nodes, and we need to know if the destination does not >> understand it. Hence I think this should stay as 01. > > I was aware that the act bits are only processed by the destination. > > My point was that ConEx only requires sender support (ie. you can have > ConEx on one half-connection but not the other - there is no need to > negotiate ConEx for a connection). So it would be very bad for a > destination to drop a packet just before delivering it to the > destination process just because it doesn't recognise a ConEx header > that it doesn't need to understand anyway. > > Note to Mirja: Given this misunderstanding, perhaps the draft should > give a reason: > "The act bits MUST be 00, because a ConEx packet needs to be > passed to the destination process even if the destination does not > understand ConEx." I agree with Bob, as the receiver does not need to proceed the option in our case at all and it does even know if it has to be there. Suresh? > > >> CDO as the first option: As you rightly note, this is just a performance >> optimization. I do believe that the performance penalty for conex-aware >> nodes will be pretty severe if they need to process all destination >> options before deciding if the CDO is present or not. > > Surely a ConEx node can stop when it gets to the CDO option (which will > usually be first). It doesn't need to continue and process all the other > options within the destopt header. > >> Please note that >> this needs to be done on *all* packets passing through the conex aware >> node. > > On packets without a destopt that is quick. > > The really bad case is for packets from senders that don't support ConEx > but are using many other destopts. Then the on-path ConEx node would > walk along every destopt until the end. > >> I do think it is OK to change the MUST to a SHOULD but with a >> severe warning. > > OK, thanks. > > Would it be OK to say "As an optimization, a ConEx implementation MAY > limit the depth of its search for CDO to two or three destination options"? My assumption was that search for the CDO if multiple options are present is not feasible in fast path. So if the CDO is not first, there are two options: 1) forward the packet to slow path 2) ignore the CDO Actually case 1) is probably no option because this would forward all present traffic to slow path because none of the traffic has a CDO at all. 2) is at least not feasible for something like a policer that really needs to look at all ConEx-enable packets. Limiting the search depth, would translate into "the CDO SHOULD be the first option and MUST be among the first X options"... is that a solution? Bob, see further below... > > > I have also added to my response to Mirja below, with an extra thought > about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way > down!)... > > >> Cheers >> Suresh >> >> On 09/08/2014 06:17 PM, Bob Briscoe wrote: >> > Mirja, >> > >> > At 16:57 03/09/2014, Mirja Kühlewind wrote: >> >> Hi again, >> >> >> >> >> >> On 28.08.2014 22:05, Bob Briscoe wrote: >> >>>>>>>>>>>> * 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? >> >>> The main problem is saying 'not available *for* control packets'. But >> >>> just changing 'for' to '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, given this is an >> >>> example, so it can be specific. >> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as >> ACK are >> >>> usually not 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 is (currently) >> available >> >>> e.g. in TCP if one endpoint has been receiving data but sending >> nothing >> >>> but pure ACKs (no user data) for some time. This is because pure >> ACKs do >> >>> not advance the sequence number, so the TCP endpoint receiving them >> >>> cannot reliably tell whether any have been lost due to congestion. >> Pure >> >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >> >> Fine for me. Done. >> >> >> >> >> >>>>>> 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... >> >>> I thought the earlier definition said that ConEx accounts for the >> size >> >>> of the IP header that contains the CDO and everything within it. >> Also, >> >>> there's the TCP header size on a pure ACK. >> >> Yes, especially when a network node accounts >> >> ConEx marks. But in the (TCP) sender we just >> >> don't care about the header bits for >> >> simplification. We are aware that all bits will >> >> be accounted but as we assume equal size packets that should be fine. >> >> >> >> >> >>> That's the basis on which I am assuming that pure ACKs are worth >> >>> counting. A pure ACK will count as 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 be hard for TCP >> to know >> >>> though. >> >> Yes, so how should I implement that? >> > I guess just assume that any IP extensions will >> > be constant on every packet in a flow, therefore >> > assuming none will be similar to assuming some. >> > >> >>>> 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. >> >>> Agreed (that this would affect tcp-mods, not destopt). >> >>> >> >>> What is 'this' that you aren't yet convinced by? >> >> 'this' is the fact that I need to changed >> >> something in the tcp mods document. I might >> >> remove the statement (if existent) that control >> >> packets should be not-ConEx capable but I would >> >> still like to recommend it because I believe it >> >> makes things overly complicated otherwise. The >> >> point is I believe that at the location in the >> >> (Linux) code where you implement the counting, >> >> you don't even have the information how large >> >> the pure ACK will be in the end... >> > See next comment. >> > >> >>>>> 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...? >> >>> I thought you were proposing that a TCP sender assumes all the >> packets >> >>> it sends are full-sized, even if they aren't. But I believe you have >> >>> said that is not what you proposed. >> >> No, when reducing the congestion counter(s) we >> >> use the actual number of payload bytes. We also >> >> use the real number of acknowledged bytes to >> >> increase the counter(s). We simply do not care >> >> about the header bytes at all assuming that on >> >> average all packets have the same size and >> >> therefor the number of (marked) header bytes >> >> (either ECN or ConEx) in total will be about right. >> > OK. I understand now. >> > >> > Ultimately TCP has to put a number in the Data >> > Offset field, so it has to know the size of its >> > own header. However, for an initial >> > (experimental) implementation, if you need your >> > proposal to assume all TCP options within one >> > flow are the same size, it would be reasonable >> > (it's not actually true, e.g. SACK, but there >> > should at least be no bias, so you will overstate as much as >> understate). >> > >> > You say earlier that it is too complicated to >> > implement code within TCP that knows the size of >> > a pure ACK. If TCP code doesn't know the size of >> > a TCP header, then Linux must be using magic >> > instead of code. Because, surely, the whole point >> > of the TCP code is to write a TCP header. >> > >> >>>>>>>>>>>> ==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? >> >>> I think this will get thrown back by the IESG if we say 'MUST be >> first'. >> >>> And I think 'SHOULD be first' is a doable implementation for >> ConEx-aware >> >>> nodes. That is sufficient for experimental. Any experiments where >> >>> general forwarding nodes access ConEx will already be reading a >> destopt >> >>> at every hop, which is not what was intended, but it would be doable >> >>> just for an experiment that wanted to prove ConEx has wider uses. >> >> I know that this might be a problem with IESG review, but... it's >> broken... >> >> >> >>> Everyone involved in IPv6 knows that the attempt to design >> extensibility >> >>> into v6 failed. It won't be news to the IESG that we can't add an >> >>> extension that can be processed at every hop on the fast path. >> >>> >> >>> If a destopt is sufficient to prove ConEx useful, then >> implementers will >> >>> want to satisfy this demand. Then >> >>> * either there is even more pressure on the IETF to address this >> failing >> >>> in v6 (and maybe someone will), >> >>> * or ConEx has to continue with this destopt solution, just like >> >>> everyone else is finding hacks round this failing in v6. >> >>> >> >>> But don't ask me. Ask Suresh. >> >> Yes! Unfortunately he did not response until >> >> now. Maybe he is/was on holidays; will ping him again. >> >> >> >> >> >>>>>>> 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? >> >>> * How to do ConEx when IPsec is also required (tunnel & transport >> modes, >> >>> and what to count). This may all be obvious now, but (IMO) it >> would still >> >>> be worth spelling out obvious things. >> >>> * How to use IPsec to protect the integrity of CDO. >> >> Okay, this is the text now: >> >> >> >> "Compatibility with use of IPsec >> >> >> >> In IPv6 there are two possible position of a >> >> Destination Option header, either before the >> >> Routing header or after the Encapsulating Security Payload (ESP) >> header. >> > BETTER?: >> > In IPv6 a Destination Option header can be placed >> > in two possible position in the order of possible >> > headers, either before the Routing header or >> > after the Encapsulating Security Payload (ESP) header. >> > REASONING: >> > We are talking about the positions where these >> > headers /would/ be if they were there - they might not actually be >> present. >> > >> >> If the packet is encrypted using IPSec tunnel >> >> mode, the CDO MUST be placed in the destination >> >> option before the Routing header such that it >> >> does not get encrypted and can be read by immediate ConEx-aware nodes. >> > BETTER?: >> > CDO MUST always be placed in a destination option >> > header placed before where the routing header >> > would be. Otherwise, if CDO were placed in the >> > latter position and an ESP header were used, the CDO would be >> encrypt the >> > REASONING: >> > (There is no need for it to ever be in the later >> > position and it's best to always be in the same place.) >> > >> > >> >> Note as the Authentication Header (AH) also only >> >> protects fields after the AH header, the CDO is not authenticated >> in this case. >> > Need to say the encapsulator copies CDO from the >> > inner IPv6 CDO before encrypting the inner. >> > >> > s/read by immediate/read by/ >> > >> > AH integrity protects the IPv6 header that encapsulates it. ESP does >> not. >> > >> > >> >> In IPSec transport mode both destination option >> >> headers can be used, as the CDO is in both cases >> >> visible to the network. If the transport network >> >> can not be trusted, the Destination Option >> >> header after the ESP header SHOULD be used to >> >> ensure integrity of the ConEx information. If an >> >> attacker would be able to remove the ConEx >> >> marks, this could cause an audit device >> >> to penalize the respective connection, while the >> >> sender cannot easily detect that ConEx information is missing." >> >> >> >> Does this seem to be right now? >> > Sorry, this is all wrong. One cannot use ESP to >> > authenticate or protect the integrity of CDO by >> > putting CDO after ESP, because ESP would then >> > encrypt CDO so ConEx-aware nodes would not be >> > able to read it. CDO always has to precede ESP, >> > which is why I said CDO MUST always be in the first destopt position. >> > >> > If the CDO header needs to be authenticated, AH >> > can be used as in the second example below. AH >> > protects the integrity of the whole IPv6 datagram >> > it is encapsulated by (except non-predictable >> > mutable fields). AH coverage includes the IPv6 >> > header and extension headers before the AH >> > header, and everything after the AH header too. Sorry that's my fault; I thought, (similar to ESP) the authentication header would only authenticate headers after the AH. (Checked now with rfc4302 that I was wrong.) >> > >> > I think it would be worth listing the two or >> > three example header sequences in the draft, as >> > below. Headers in [] need not be present. Headers in {} are encrypted. >> > >> > Transport mode without the integrity of CDO protected: >> > IPv6 >> > [Hop-by-Hop] >> > [Routing] >> > Destopt(CDO[,...]) >> > [Fragment] >> > ESP{ >> > [Destopt] >> > Upper-Layer >> > } >> > >> > Transport mode with the integrity of CDO protected: >> > IPv6 >> > [Hop-by-Hop] >> > [Routing] >> > Destopt(CDO[,...]) >> > [Fragment] >> > AH >> > ESP{ >> > [Destopt] >> > Upper-Layer >> > } >> > >> > >> > Tunnel mode: >> > IPv6 >> > [Hop-by-Hop] >> > [Routing] >> > Destopt(CDO-copy[,...]) >> > [Fragment] >> > ESP{ >> > IPv6 >> > Destopt(CDO[,...]) >> > Transport Payload >> > } >> > >> > For ESP in tunnel mode, as already stated in the >> > draft, the tunnel ingress MUST copy the CDO from >> > the destopt in the inner, then write a copy of >> > the CDO header into a destopt header in the outer. >> > >> > I think this updates RFC2406. However, it is >> > possible that 2406 already requires an ESP >> > ingress to copy any extension headers, up to and >> > including Fragmentation, to the outer. Because >> > all these headers are designed to be visible to >> > nodes on the path. Suresh may know this. > > I checked overnight and copying extension headers is contrary to the > IPSec architecture. > > "IPv6 -- Header > Construction for Tunnel Mode" says: > "Extension headers never copied" > > On reflection, I don't think we should update RFC2401 for ConEx. If I > were on the IESG, I would not approve that. IPsec needs to have simple > rules without exceptions. > > When we chose destopt as the mechanism for ConEx, we knew it wasn't > going to interact well with tunnels. I think the best approach is to say, > "Currently, the IPv6 protocol architecture does not provide a > mechanism for new extension headers to be copied to the outer. Therefore > ConEx functions will have to search for the CDO option within inner > headers, and ConEx will not work at all over the extent of an ESP tunnel". So all in all, this simplifies thing to basically "CDO MUST be placed in the destination option header before the AH and/or EPS (if present)." (+ our text just above on not interacting with tunnel mode) Right? Mirja > > > Bob > > >> > >> > To protect the integrity of the outer IPv6 >> > datagram, including protecting the copy of CDO, >> > an AH header (not shown) could be added before ESP. >> > >> > [A worse alternative (no need to mention this): >> > If the integrity of CDO but not other headers >> > needed to be protected, ESP with authentication >> > enabled could be used, which causes >> > authentication data to be added at the end of the >> > payload (not shown). Then, before decapsulation, >> > the tunnel egress would have to record the value >> > of CDO-copy. Having decrypted the inner, it could >> > then check that CDO-copy matched the CDO in the >> > inner. However, that would require another >> > update to RFC2406, so using AH would be >> > preferable, given we don't want to make ConEx >> > depend on updating both ends of an ESP tunnel - one end is bad enough.] >> > >> > HTH >> > Sorry for taking so long - I wrote most of this >> > on a plane on Thu, but left some fact checking >> > for when I got online, and this is the first chance I've had to get >> back to it. >> > >> > Cheers >> > >> > >> > >> > Bob >> > >> >>>>>>>>> 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. " >> >>> OK. Rather than implying that equipment has evolved conscious >> awareness, >> >>> a better formulation would be something like: >> >>> "..the configuration of the tunnel ingress and the ConEx nodes is >> >>> co-ordinated." >> >>> >> >>> Nits: >> >>> s/SHOULD not/SHOULD NOT/ >> >>> s/accounted/counted/ >> >>> (in English, accounted is not a transitive verb, it has to have >> 'for' >> >>> after it) >> >>> s/ingree/ingress/ >> >>> s/theses/these/ >> >> Done. >> >> >> >> >> >>> We're getting there! >> >> Yes...! >> >> >> >> Mirja >> >> >> >> >> >>> 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 >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>> ==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 >> >>>> ------------------------------------------ >> >>> ________________________________________________________________ >> >>> 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 >> > >> > > > ________________________________________________________________ > 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 Sep 9 07:41:31 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E091A6FB2 for ; Tue, 9 Sep 2014 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 0YlAMoD9ujSJ for ; Tue, 9 Sep 2014 07:41: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 0E4971A0AE9 for ; Tue, 9 Sep 2014 07:41:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 71832D930A; Tue, 9 Sep 2014 16:41: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 bUY7FwuS98fP; Tue, 9 Sep 2014 16:41: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 1C6CFD9304; Tue, 9 Sep 2014 16:41:21 +0200 (MEST) Message-ID: <540F1190.4060706@tik.ee.ethz.ch> Date: Tue, 09 Sep 2014 16:41:20 +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> <53FF4E3F.4060502@tik.ee.ethz.ch> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> In-Reply-To: <201409082217.s88MHFDj018480@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/TnrPCFrPdAzLNGOzf44rDeniKN4 Cc: 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, 09 Sep 2014 14:41:29 -0000 Hi, one quick comment on the Linux code: Of course you can figure out the size of a pure ACK in the Liunx code, but the IP processing is kind of separated form the TCP processing. While you would implement all the ConEx accounting stuff in the TCP processing (and then set a flag if a ConEx mark should be set or not in the IP header later on), I believe, it is not totally obvious how large the IP header will be. Of course you can get this information if needed but it's not like you only need to check one variable. I will again check the code (together with David) and then we will see what to do with the TCP mods draft. Mirja On 09.09.2014 00:17, Bob Briscoe wrote: > Mirja, > > At 16:57 03/09/2014, Mirja Kühlewind wrote: >> Hi again, >> >> >> On 28.08.2014 22:05, Bob Briscoe wrote: >>>>>>>>>>>> * 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? >>> >>> The main problem is saying 'not available *for* control packets'. But >>> just changing 'for' to '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, given this is an >>> example, so it can be specific. >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as ACK are >>> usually not 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 is (currently) available >>> e.g. in TCP if one endpoint has been receiving data but sending nothing >>> but pure ACKs (no user data) for some time. This is because pure ACKs do >>> not advance the sequence number, so the TCP endpoint receiving them >>> cannot reliably tell whether any have been lost due to congestion. Pure >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >> >> Fine for me. Done. >> >> >>>>>> 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... >>> >>> I thought the earlier definition said that ConEx accounts for the size >>> of the IP header that contains the CDO and everything within it. Also, >>> there's the TCP header size on a pure ACK. >> >> Yes, especially when a network node accounts ConEx marks. But in the >> (TCP) sender we just don't care about the header bits for >> simplification. We are aware that all bits will be accounted but as we >> assume equal size packets that should be fine. >> >> >>> That's the basis on which I am assuming that pure ACKs are worth >>> counting. A pure ACK will count as 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 be hard for TCP to know >>> though. >> >> Yes, so how should I implement that? > > I guess just assume that any IP extensions will be constant on every > packet in a flow, therefore assuming none will be similar to assuming some. > >>>> 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. >>> >>> Agreed (that this would affect tcp-mods, not destopt). >>> >>> What is 'this' that you aren't yet convinced by? >> >> 'this' is the fact that I need to changed something in the tcp mods >> document. I might remove the statement (if existent) that control >> packets should be not-ConEx capable but I would still like to >> recommend it because I believe it makes things overly complicated >> otherwise. The point is I believe that at the location in the (Linux) >> code where you implement the counting, you don't even have the >> information how large the pure ACK will be in the end... > > See next comment. > >>>>> 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...? >>> >>> I thought you were proposing that a TCP sender assumes all the packets >>> it sends are full-sized, even if they aren't. But I believe you have >>> said that is not what you proposed. >> >> No, when reducing the congestion counter(s) we use the actual number >> of payload bytes. We also use the real number of acknowledged bytes to >> increase the counter(s). We simply do not care about the header bytes >> at all assuming that on average all packets have the same size and >> therefor the number of (marked) header bytes (either ECN or ConEx) in >> total will be about right. > > OK. I understand now. > > Ultimately TCP has to put a number in the Data Offset field, so it has > to know the size of its own header. However, for an initial > (experimental) implementation, if you need your proposal to assume all > TCP options within one flow are the same size, it would be reasonable > (it's not actually true, e.g. SACK, but there should at least be no > bias, so you will overstate as much as understate). > > You say earlier that it is too complicated to implement code within TCP > that knows the size of a pure ACK. If TCP code doesn't know the size of > a TCP header, then Linux must be using magic instead of code. Because, > surely, the whole point of the TCP code is to write a TCP header. > >>>>>>>>>>>> ==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? >>> >>> I think this will get thrown back by the IESG if we say 'MUST be first'. >>> And I think 'SHOULD be first' is a doable implementation for ConEx-aware >>> nodes. That is sufficient for experimental. Any experiments where >>> general forwarding nodes access ConEx will already be reading a destopt >>> at every hop, which is not what was intended, but it would be doable >>> just for an experiment that wanted to prove ConEx has wider uses. >> >> I know that this might be a problem with IESG review, but... it's >> broken... >> >>> >>> Everyone involved in IPv6 knows that the attempt to design extensibility >>> into v6 failed. It won't be news to the IESG that we can't add an >>> extension that can be processed at every hop on the fast path. >>> >>> If a destopt is sufficient to prove ConEx useful, then implementers will >>> want to satisfy this demand. Then >>> * either there is even more pressure on the IETF to address this failing >>> in v6 (and maybe someone will), >>> * or ConEx has to continue with this destopt solution, just like >>> everyone else is finding hacks round this failing in v6. >>> >>> But don't ask me. Ask Suresh. >> Yes! Unfortunately he did not response until now. Maybe he is/was on >> holidays; will ping him again. >> >> >>>>>>> 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? >> > >>> * How to do ConEx when IPsec is also required (tunnel & transport modes, >>> and what to count). This may all be obvious now, but (IMO) it would >>> still >> > be worth spelling out obvious things. >>> * How to use IPsec to protect the integrity of CDO. >> >> Okay, this is the text now: >> >> "Compatibility with use of IPsec >> >> In IPv6 there are two possible position of a Destination Option >> header, either before the Routing header or after the Encapsulating >> Security Payload (ESP) header. > > BETTER?: > In IPv6 a Destination Option header can be placed in two possible > position in the order of possible headers, either before the Routing > header or after the Encapsulating Security Payload (ESP) header. > REASONING: > We are talking about the positions where these headers /would/ be if > they were there - they might not actually be present. > >> If the packet is encrypted using IPSec tunnel mode, the CDO MUST be >> placed in the destination option before the Routing header such that >> it does not get encrypted and can be read by immediate ConEx-aware nodes. > > BETTER?: > CDO MUST always be placed in a destination option header placed before > where the routing header would be. Otherwise, if CDO were placed in the > latter position and an ESP header were used, the CDO would be encrypt the > REASONING: > (There is no need for it to ever be in the later position and it's best > to always be in the same place.) > > >> Note as the Authentication Header (AH) also only protects fields after >> the AH header, the CDO is not authenticated in this case. > > Need to say the encapsulator copies CDO from the inner IPv6 CDO before > encrypting the inner. > > s/read by immediate/read by/ > > AH integrity protects the IPv6 header that encapsulates it. ESP does not. > > >> In IPSec transport mode both destination option headers can be used, >> as the CDO is in both cases visible to the network. If the transport >> network can not be trusted, the Destination Option header after the >> ESP header SHOULD be used to ensure integrity of the ConEx >> information. If an attacker would be able to remove the ConEx marks, >> this could cause an audit device to penalize the respective >> connection, while the sender cannot easily detect that ConEx >> information is missing." >> >> Does this seem to be right now? > > Sorry, this is all wrong. One cannot use ESP to authenticate or protect > the integrity of CDO by putting CDO after ESP, because ESP would then > encrypt CDO so ConEx-aware nodes would not be able to read it. CDO > always has to precede ESP, which is why I said CDO MUST always be in the > first destopt position. > > If the CDO header needs to be authenticated, AH can be used as in the > second example below. AH protects the integrity of the whole IPv6 > datagram it is encapsulated by (except non-predictable mutable fields). > AH coverage includes the IPv6 header and extension headers before the AH > header, and everything after the AH header too. > > I think it would be worth listing the two or three example header > sequences in the draft, as below. Headers in [] need not be present. > Headers in {} are encrypted. > > Transport mode without the integrity of CDO protected: > IPv6 > [Hop-by-Hop] > [Routing] > Destopt(CDO[,...]) > [Fragment] > ESP{ > [Destopt] > Upper-Layer > } > > Transport mode with the integrity of CDO protected: > IPv6 > [Hop-by-Hop] > [Routing] > Destopt(CDO[,...]) > [Fragment] > AH > ESP{ > [Destopt] > Upper-Layer > } > > > Tunnel mode: > IPv6 > [Hop-by-Hop] > [Routing] > Destopt(CDO-copy[,...]) > [Fragment] > ESP{ > IPv6 > Destopt(CDO[,...]) > Transport Payload > } > > For ESP in tunnel mode, as already stated in the draft, the tunnel > ingress MUST copy the CDO from the destopt in the inner, then write a > copy of the CDO header into a destopt header in the outer. > > I think this updates RFC2406. However, it is possible that 2406 already > requires an ESP ingress to copy any extension headers, up to and > including Fragmentation, to the outer. Because all these headers are > designed to be visible to nodes on the path. Suresh may know this. > > To protect the integrity of the outer IPv6 datagram, including > protecting the copy of CDO, an AH header (not shown) could be added > before ESP. > > [A worse alternative (no need to mention this): If the integrity of CDO > but not other headers needed to be protected, ESP with authentication > enabled could be used, which causes authentication data to be added at > the end of the payload (not shown). Then, before decapsulation, the > tunnel egress would have to record the value of CDO-copy. Having > decrypted the inner, it could then check that CDO-copy matched the CDO > in the inner. However, that would require another update to RFC2406, so > using AH would be preferable, given we don't want to make ConEx depend > on updating both ends of an ESP tunnel - one end is bad enough.] > > HTH > Sorry for taking so long - I wrote most of this on a plane on Thu, but > left some fact checking for when I got online, and this is the first > chance I've had to get back to it. > > Cheers > > > > Bob > >>>>>>>>> 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. " >>> >>> OK. Rather than implying that equipment has evolved conscious awareness, >>> a better formulation would be something like: >>> "..the configuration of the tunnel ingress and the ConEx nodes is >>> co-ordinated." >>> >>> Nits: >>> s/SHOULD not/SHOULD NOT/ >>> s/accounted/counted/ >>> (in English, accounted is not a transitive verb, it has to have 'for' >>> after it) >>> s/ingree/ingress/ >>> s/theses/these/ >> >> Done. >> >> >>> We're getting there! >> Yes...! >> >> Mirja >> >> >>> 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 >>>>>>>> >>>>>>>> >>>>>>>>>>>> ==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 >>>> ------------------------------------------ >>> >>> ________________________________________________________________ >>> 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 Sep 9 10:44:01 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB78B1A802F for ; Tue, 9 Sep 2014 10:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 BChwTlpRrYSS for ; Tue, 9 Sep 2014 10:43:53 -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 BAA801A802B for ; Tue, 9 Sep 2014 10:43:52 -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, 9 Sep 2014 18:43:47 +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, 9 Sep 2014 18:43:49 +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, 9 Sep 2014 18:43:44 +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 s89HheQJ021974; Tue, 9 Sep 2014 18:43:40 +0100 Message-ID: <201409091743.s89HheQJ021974@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 9 Sep 2014 18:43:39 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <540F0C78.7050309@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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> <540F0C78.7050309@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/Fzh9JPJ14CCzyAyvQRVPhPIBVTo Cc: Carlos Ucendo , ConEx IETF list Subject: Re: [conex] Act bits and Positioning (Was Re: 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, 09 Sep 2014 17:44:00 -0000 Mirja, Agree with you on all 3 new responses: * act bits =3D 00 * CDO SHOULD be first destopt, and MUST be among=20 the first X destopts: that works for me. X=3D3? * CDO is always in the destopt position before=20 any IPsec, and ConEx doesn't work within an ESP tunnel. Bob At 15:19 09/09/2014, Mirja K=FChlewind wrote: >Hi, > >see inline > >On 09.09.2014 09:59, Bob Briscoe wrote: >>Suresh, >> >>At 05:36 09/09/2014, Suresh Krishnan wrote: >>>Hi Bob, >>> Thanks a lot for your comments. I will respond to two specific issues >>>that you brought up >>> >>>act bits being 01: Please note that the Conex option is a *destination* >>>option. Non conex-aware nodes on path will not even process the option. >>>So we do not need to be worried about the packet being dropped by >>>intermediate nodes, and we need to know if the destination does not >>>understand it. Hence I think this should stay as 01. >> >>I was aware that the act bits are only processed by the destination. >> >>My point was that ConEx only requires sender support (ie. you can have >>ConEx on one half-connection but not the other - there is no need to >>negotiate ConEx for a connection). So it would be very bad for a >>destination to drop a packet just before delivering it to the >>destination process just because it doesn't recognise a ConEx header >>that it doesn't need to understand anyway. >> >>Note to Mirja: Given this misunderstanding, perhaps the draft should >>give a reason: >> "The act bits MUST be 00, because a ConEx packet needs to be >>passed to the destination process even if the destination does not >>understand ConEx." >I agree with Bob, as the receiver does not need=20 >to proceed the option in our case at all and it=20 >does even know if it has to be there. Suresh? > >> >> >>>CDO as the first option: As you rightly note, this is just a performance >>>optimization. I do believe that the performance penalty for conex-aware >>>nodes will be pretty severe if they need to process all destination >>>options before deciding if the CDO is present or not. >> >>Surely a ConEx node can stop when it gets to the CDO option (which will >>usually be first). It doesn't need to continue and process all the other >>options within the destopt header. >> >>>Please note that >>>this needs to be done on *all* packets passing through the conex aware >>>node. >> >>On packets without a destopt that is quick. >> >>The really bad case is for packets from senders that don't support ConEx >>but are using many other destopts. Then the on-path ConEx node would >>walk along every destopt until the end. >> >>>I do think it is OK to change the MUST to a SHOULD but with a >>>severe warning. >> >>OK, thanks. >> >>Would it be OK to say "As an optimization, a ConEx implementation MAY >>limit the depth of its search for CDO to two or three destination= options"? >My assumption was that search for the CDO if=20 >multiple options are present is not feasible in fast path. > >So if the CDO is not first, there are two options: >1) forward the packet to slow path >2) ignore the CDO > >Actually case 1) is probably no option because=20 >this would forward all present traffic to slow=20 >path because none of the traffic has a CDO at all. > >2) is at least not feasible for something like a=20 >policer that really needs to look at all ConEx-enable packets. > >Limiting the search depth, would translate into=20 >"the CDO SHOULD be the first option and MUST be=20 >among the first X options"... is that a solution? > > >Bob, see further below... > >> >> >>I have also added to my response to Mirja below, with an extra thought >>about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way >>down!)... >> >> >>>Cheers >>>Suresh >>> >>>On 09/08/2014 06:17 PM, Bob Briscoe wrote: >>> > Mirja, >>> > >>> > At 16:57 03/09/2014, Mirja K=FChlewind wrote: >>> >> Hi again, >>> >> >>> >> >>> >> On 28.08.2014 22:05, Bob Briscoe wrote: >>> >>>>>>>>>>>> * 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? >>> >>> The main problem is saying 'not available *for* control packets'.= But >>> >>> just changing 'for' to '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, given this is an >>> >>> example, so it can be specific. >>> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as >>>ACK are >>> >>> usually not 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 is (currently) >>>available >>> >>> e.g. in TCP if one endpoint has been receiving data but sending >>>nothing >>> >>> but pure ACKs (no user data) for some time. This is because pure >>>ACKs do >>> >>> not advance the sequence number, so the TCP endpoint receiving them >>> >>> cannot reliably tell whether any have been lost due to congestion. >>>Pure >>> >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >>> >> Fine for me. Done. >>> >> >>> >> >>> >>>>>> 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... >>> >>> I thought the earlier definition said that ConEx accounts for the >>>size >>> >>> of the IP header that contains the CDO and everything within it. >>>Also, >>> >>> there's the TCP header size on a pure ACK. >>> >> Yes, especially when a network node accounts >>> >> ConEx marks. But in the (TCP) sender we just >>> >> don't care about the header bits for >>> >> simplification. We are aware that all bits will >>> >> be accounted but as we assume equal size packets that should be fine. >>> >> >>> >> >>> >>> That's the basis on which I am assuming that pure ACKs are worth >>> >>> counting. A pure ACK will count as 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 be hard for TCP >>>to know >>> >>> though. >>> >> Yes, so how should I implement that? >>> > I guess just assume that any IP extensions will >>> > be constant on every packet in a flow, therefore >>> > assuming none will be similar to assuming some. >>> > >>> >>>> 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. >>> >>> Agreed (that this would affect tcp-mods, not destopt). >>> >>> >>> >>> What is 'this' that you aren't yet convinced by? >>> >> 'this' is the fact that I need to changed >>> >> something in the tcp mods document. I might >>> >> remove the statement (if existent) that control >>> >> packets should be not-ConEx capable but I would >>> >> still like to recommend it because I believe it >>> >> makes things overly complicated otherwise. The >>> >> point is I believe that at the location in the >>> >> (Linux) code where you implement the counting, >>> >> you don't even have the information how large >>> >> the pure ACK will be in the end... >>> > See next comment. >>> > >>> >>>>> 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...? >>> >>> I thought you were proposing that a TCP sender assumes all the >>>packets >>> >>> it sends are full-sized, even if they aren't. But I believe you have >>> >>> said that is not what you proposed. >>> >> No, when reducing the congestion counter(s) we >>> >> use the actual number of payload bytes. We also >>> >> use the real number of acknowledged bytes to >>> >> increase the counter(s). We simply do not care >>> >> about the header bytes at all assuming that on >>> >> average all packets have the same size and >>> >> therefor the number of (marked) header bytes >>> >> (either ECN or ConEx) in total will be about right. >>> > OK. I understand now. >>> > >>> > Ultimately TCP has to put a number in the Data >>> > Offset field, so it has to know the size of its >>> > own header. However, for an initial >>> > (experimental) implementation, if you need your >>> > proposal to assume all TCP options within one >>> > flow are the same size, it would be reasonable >>> > (it's not actually true, e.g. SACK, but there >>> > should at least be no bias, so you will overstate as much as >>>understate). >>> > >>> > You say earlier that it is too complicated to >>> > implement code within TCP that knows the size of >>> > a pure ACK. If TCP code doesn't know the size of >>> > a TCP header, then Linux must be using magic >>> > instead of code. Because, surely, the whole point >>> > of the TCP code is to write a TCP header. >>> > >>> >>>>>>>>>>>> =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. traffic management= or >>> >>>> multipath routing where 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 we say 'MUST be >>>first'. >>> >>> And I think 'SHOULD be first' is a doable implementation for >>>ConEx-aware >>> >>> nodes. That is sufficient for experimental. Any experiments where >>> >>> general forwarding nodes access ConEx will already be reading a >>>destopt >>> >>> at every hop, which is not what was intended, but it would be doable >>> >>> just for an experiment that wanted to prove ConEx has wider uses. >>> >> I know that this might be a problem with IESG review, but... it's >>>broken... >>> >> >>> >>> Everyone involved in IPv6 knows that the attempt to design >>>extensibility >>> >>> into v6 failed. It won't be news to the IESG that we can't add an >>> >>> extension that can be processed at every hop on the fast path. >>> >>> >>> >>> If a destopt is sufficient to prove ConEx useful, then >>>implementers will >>> >>> want to satisfy this demand. Then >>> >>> * either there is even more pressure on the IETF to address this >>>failing >>> >>> in v6 (and maybe someone will), >>> >>> * or ConEx has to continue with this destopt solution, just like >>> >>> everyone else is finding hacks round this failing in v6. >>> >>> >>> >>> But don't ask me. Ask Suresh. >>> >> Yes! Unfortunately he did not response until >>> >> now. Maybe he is/was on holidays; will ping him again. >>> >> >>> >> >>> >>>>>>> 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? >>> >>> * How to do ConEx when IPsec is also required (tunnel & transport >>>modes, >>> >>> and what to count). This may all be obvious now, but (IMO) it >>>would still >>> >>> be worth spelling out obvious things. >>> >>> * How to use IPsec to protect the integrity of CDO. >>> >> Okay, this is the text now: >>> >> >>> >> "Compatibility with use of IPsec >>> >> >>> >> In IPv6 there are two possible position of a >>> >> Destination Option header, either before the >>> >> Routing header or after the Encapsulating Security Payload (ESP) >>>header. >>> > BETTER?: >>> > In IPv6 a Destination Option header can be placed >>> > in two possible position in the order of possible >>> > headers, either before the Routing header or >>> > after the Encapsulating Security Payload (ESP) header. >>> > REASONING: >>> > We are talking about the positions where these >>> > headers /would/ be if they were there - they might not actually be >>>present. >>> > >>> >> If the packet is encrypted using IPSec tunnel >>> >> mode, the CDO MUST be placed in the destination >>> >> option before the Routing header such that it >>> >> does not get encrypted and can be read by immediate ConEx-aware= nodes. >>> > BETTER?: >>> > CDO MUST always be placed in a destination option >>> > header placed before where the routing header >>> > would be. Otherwise, if CDO were placed in the >>> > latter position and an ESP header were used, the CDO would be >>>encrypt the >>> > REASONING: >>> > (There is no need for it to ever be in the later >>> > position and it's best to always be in the same place.) >>> > >>> > >>> >> Note as the Authentication Header (AH) also only >>> >> protects fields after the AH header, the CDO is not authenticated >>>in this case. >>> > Need to say the encapsulator copies CDO from the >>> > inner IPv6 CDO before encrypting the inner. >>> > >>> > s/read by immediate/read by/ >>> > >>> > AH integrity protects the IPv6 header that encapsulates it. ESP does >>>not. >>> > >>> > >>> >> In IPSec transport mode both destination option >>> >> headers can be used, as the CDO is in both cases >>> >> visible to the network. If the transport network >>> >> can not be trusted, the Destination Option >>> >> header after the ESP header SHOULD be used to >>> >> ensure integrity of the ConEx information. If an >>> >> attacker would be able to remove the ConEx >>> >> marks, this could cause an audit device >>> >> to penalize the respective connection, while the >>> >> sender cannot easily detect that ConEx information is missing." >>> >> >>> >> Does this seem to be right now? >>> > Sorry, this is all wrong. One cannot use ESP to >>> > authenticate or protect the integrity of CDO by >>> > putting CDO after ESP, because ESP would then >>> > encrypt CDO so ConEx-aware nodes would not be >>> > able to read it. CDO always has to precede ESP, >>> > which is why I said CDO MUST always be in the first destopt position. >>> > >>> > If the CDO header needs to be authenticated, AH >>> > can be used as in the second example below. AH >>> > protects the integrity of the whole IPv6 datagram >>> > it is encapsulated by (except non-predictable >>> > mutable fields). AH coverage includes the IPv6 >>> > header and extension headers before the AH >>> > header, and everything after the AH header too. >Sorry that's my fault; I thought, (similar to=20 >ESP) the authentication header would only=20 >authenticate headers after the AH. (Checked now with rfc4302 that I was= wrong.) > >>> > >>> > I think it would be worth listing the two or >>> > three example header sequences in the draft, as >>> > below. Headers in [] need not be present. Headers in {} are encrypted. >>> > >>> > Transport mode without the integrity of CDO protected: >>> > IPv6 >>> > [Hop-by-Hop] >>> > [Routing] >>> > Destopt(CDO[,...]) >>> > [Fragment] >>> > ESP{ >>> > [Destopt] >>> > Upper-Layer >>> > } >>> > >>> > Transport mode with the integrity of CDO protected: >>> > IPv6 >>> > [Hop-by-Hop] >>> > [Routing] >>> > Destopt(CDO[,...]) >>> > [Fragment] >>> > AH >>> > ESP{ >>> > [Destopt] >>> > Upper-Layer >>> > } >>> > >>> > >>> > Tunnel mode: >>> > IPv6 >>> > [Hop-by-Hop] >>> > [Routing] >>> > Destopt(CDO-copy[,...]) >>> > [Fragment] >>> > ESP{ >>> > IPv6 >>> > Destopt(CDO[,...]) >>> > Transport Payload >>> > } >>> > >>> > For ESP in tunnel mode, as already stated in the >>> > draft, the tunnel ingress MUST copy the CDO from >>> > the destopt in the inner, then write a copy of >>> > the CDO header into a destopt header in the outer. >>> > >>> > I think this updates RFC2406. However, it is >>> > possible that 2406 already requires an ESP >>> > ingress to copy any extension headers, up to and >>> > including Fragmentation, to the outer. Because >>> > all these headers are designed to be visible to >>> > nodes on the path. Suresh may know this. >> >>I checked overnight and copying extension headers is contrary to the >>IPSec architecture. >> >> "IPv6 -- Header >>Construction for Tunnel Mode" says: >> "Extension headers never copied" >> >>On reflection, I don't think we should update RFC2401 for ConEx. If I >>were on the IESG, I would not approve that. IPsec needs to have simple >>rules without exceptions. >> >>When we chose destopt as the mechanism for ConEx, we knew it wasn't >>going to interact well with tunnels. I think the best approach is to say, >> "Currently, the IPv6 protocol architecture does not provide a >>mechanism for new extension headers to be copied to the outer. Therefore >>ConEx functions will have to search for the CDO option within inner >>headers, and ConEx will not work at all over the extent of an ESP tunnel". > >So all in all, this simplifies thing to=20 >basically "CDO MUST be placed in the destination=20 >option header before the AH and/or EPS (if present)." > >(+ our text just above on not interacting with tunnel mode) > >Right? > >Mirja > >> >> >>Bob >> >> >>> > >>> > To protect the integrity of the outer IPv6 >>> > datagram, including protecting the copy of CDO, >>> > an AH header (not shown) could be added before ESP. >>> > >>> > [A worse alternative (no need to mention this): >>> > If the integrity of CDO but not other headers >>> > needed to be protected, ESP with authentication >>> > enabled could be used, which causes >>> > authentication data to be added at the end of the >>> > payload (not shown). Then, before decapsulation, >>> > the tunnel egress would have to record the value >>> > of CDO-copy. Having decrypted the inner, it could >>> > then check that CDO-copy matched the CDO in the >>> > inner. However, that would require another >>> > update to RFC2406, so using AH would be >>> > preferable, given we don't want to make ConEx >>> > depend on updating both ends of an ESP tunnel - one end is bad= enough.] >>> > >>> > HTH >>> > Sorry for taking so long - I wrote most of this >>> > on a plane on Thu, but left some fact checking >>> > for when I got online, and this is the first chance I've had to get >>>back to it. >>> > >>> > Cheers >>> > >>> > >>> > >>> > Bob >>> > >>> >>>>>>>>> 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. " >>> >>> OK. Rather than implying that equipment has evolved conscious >>>awareness, >>> >>> a better formulation would be something like: >>> >>> "..the configuration of the tunnel ingress and the ConEx nodes is >>> >>> co-ordinated." >>> >>> >>> >>> Nits: >>> >>> s/SHOULD not/SHOULD NOT/ >>> >>> s/accounted/counted/ >>> >>> (in English, accounted is not a transitive verb, it has to have >>>'for' >>> >>> after it) >>> >>> s/ingree/ingress/ >>> >>> s/theses/these/ >>> >> Done. >>> >> >>> >> >>> >>> We're getting there! >>> >> Yes...! >>> >> >>> >> Mirja >>> >> >>> >> >>> >>> 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 >>> >> -- >>> >> ------------------------------------------ >>> >> 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 >>> > >>> > >> >>________________________________________________________________ >>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 Thu Sep 11 20:33:28 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 D7A8F1A0363 for ; Thu, 11 Sep 2014 20:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lri2T_NlY3k for ; Thu, 11 Sep 2014 20:33:18 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16321A029C for ; Thu, 11 Sep 2014 20:33:17 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-64-541213eb0d61 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D3.05.05330.BE312145; Thu, 11 Sep 2014 23:28:11 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 23:33:15 -0400 From: Suresh Krishnan To: "mirja.kuehlewind@tik.ee.ethz.ch" , "bob.briscoe@bt.com" Thread-Topic: Act bits and Positioning (Was Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06) Thread-Index: AQHPzFWlxntQt/Qy3UOU9tEO+qJSEpv82+d2 Date: Fri, 12 Sep 2014 03:33:15 +0000 Message-ID: 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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> <540F0C78.7050309@tik.ee.ethz.ch>, <201409091743.s89HheQJ021974@bagheera.jungle.bt.co.uk> In-Reply-To: <201409091743.s89HheQJ021974@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF6288300FDeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonVve1sFCIQdtFS4vp678wWhy69pPR YsPqKSwWL2e2sDmweLR9mczksWTJTyaPJ3+3MHsc+/CVLYAlissmJTUnsyy1SN8ugSvjT896 9oLXE9krlux+yd7AeKCJrYuRk0NCwESiZ8t6JghbTOLCvfVgcSGBo4wSR266dzFyAdnLGSX+ TvjNDpJgA2rYsPMzWIOIQIlE34zJjCA2s4CLxKz+NawgtrBAssSC+33sEDUpEp3XO6HqjSQ2 /VnHAmKzCKhK3H98A2wZr4CvRNfbU6wQy3rZJHbt3QlWxCngLNG2eBoziM0IdN33U2uYIJaJ S9x6Mh/qagGJJXvOM0PYohIvH/9jhajJlzg/cSsrxAJBiZMzn7BMYBSZhaR9FpKyWUjKIOJ6 EjemTmGDsLUlli18zQxh60rM+HeIBVl8ASP7KkaO0uLUstx0I4NNjMBYOybBpruDcc9Ly0OM AhyMSjy8D04KhAixJpYVV+YeYpTmYFES551VOy9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A2PH0vSwvJjYX5VhM3wvPvzK77zdc67GVcfld5/8PLN2ehW/WNzXEvYzef/qFi1svpR38765 74lDzXGz9mf6nVkwo4st4Wvn+1XBwiIiBhtseO48uuerJRR4nX+rL8/xU8L79JKVOOXcI38n ihwxnShp/FbzQcxSucL49m+xSyZ4/bIUyFy5h1uJpTgj0VCLuag4EQDOdDJFlgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/conex/_IMUjDwUzX-XkBPu4IVRsazBcOM Cc: "ralli@tid.es" , "conex@ietf.org" Subject: Re: [conex] Act bits and Positioning (Was Re: 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: Fri, 12 Sep 2014 03:33:27 -0000 --_000_E87B771635882B4BA20096B589152EF6288300FDeusaamb107erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bob/Mirja, Sounds fine to me as well. I can live with any value of X but the only one = that really makes sense is 1 :-) Thanks Suresh -----Original Message----- From: Bob Briscoe [bob.briscoe@bt.com] Received: Tuesday, 09 Sep 2014, 1:44PM To: Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch] CC: Suresh Krishnan [suresh.krishnan@ericsson.com]; Carlos Ucendo [ralli@ti= d.es]; ConEx IETF list [conex@ietf.org] Subject: Re: Act bits and Positioning (Was Re: [conex] Fwd: Review: draft-i= etf-conex-destopt-06) Mirja, Agree with you on all 3 new responses: * act bits =3D 00 * CDO SHOULD be first destopt, and MUST be among the first X destopts: that works for me. X=3D3? * CDO is always in the destopt position before any IPsec, and ConEx doesn't work within an ESP tunnel. Bob At 15:19 09/09/2014, Mirja K=FChlewind wrote: >Hi, > >see inline > >On 09.09.2014 09:59, Bob Briscoe wrote: >>Suresh, >> >>At 05:36 09/09/2014, Suresh Krishnan wrote: >>>Hi Bob, >>> Thanks a lot for your comments. I will respond to two specific issues >>>that you brought up >>> >>>act bits being 01: Please note that the Conex option is a *destination* >>>option. Non conex-aware nodes on path will not even process the option. >>>So we do not need to be worried about the packet being dropped by >>>intermediate nodes, and we need to know if the destination does not >>>understand it. Hence I think this should stay as 01. >> >>I was aware that the act bits are only processed by the destination. >> >>My point was that ConEx only requires sender support (ie. you can have >>ConEx on one half-connection but not the other - there is no need to >>negotiate ConEx for a connection). So it would be very bad for a >>destination to drop a packet just before delivering it to the >>destination process just because it doesn't recognise a ConEx header >>that it doesn't need to understand anyway. >> >>Note to Mirja: Given this misunderstanding, perhaps the draft should >>give a reason: >> "The act bits MUST be 00, because a ConEx packet needs to be >>passed to the destination process even if the destination does not >>understand ConEx." >I agree with Bob, as the receiver does not need >to proceed the option in our case at all and it >does even know if it has to be there. Suresh? > >> >> >>>CDO as the first option: As you rightly note, this is just a performance >>>optimization. I do believe that the performance penalty for conex-aware >>>nodes will be pretty severe if they need to process all destination >>>options before deciding if the CDO is present or not. >> >>Surely a ConEx node can stop when it gets to the CDO option (which will >>usually be first). It doesn't need to continue and process all the other >>options within the destopt header. >> >>>Please note that >>>this needs to be done on *all* packets passing through the conex aware >>>node. >> >>On packets without a destopt that is quick. >> >>The really bad case is for packets from senders that don't support ConEx >>but are using many other destopts. Then the on-path ConEx node would >>walk along every destopt until the end. >> >>>I do think it is OK to change the MUST to a SHOULD but with a >>>severe warning. >> >>OK, thanks. >> >>Would it be OK to say "As an optimization, a ConEx implementation MAY >>limit the depth of its search for CDO to two or three destination options= "? >My assumption was that search for the CDO if >multiple options are present is not feasible in fast path. > >So if the CDO is not first, there are two options: >1) forward the packet to slow path >2) ignore the CDO > >Actually case 1) is probably no option because >this would forward all present traffic to slow >path because none of the traffic has a CDO at all. > >2) is at least not feasible for something like a >policer that really needs to look at all ConEx-enable packets. > >Limiting the search depth, would translate into >"the CDO SHOULD be the first option and MUST be >among the first X options"... is that a solution? > > >Bob, see further below... > >> >> >>I have also added to my response to Mirja below, with an extra thought >>about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way >>down!)... >> >> >>>Cheers >>>Suresh >>> >>>On 09/08/2014 06:17 PM, Bob Briscoe wrote: >>> > Mirja, >>> > >>> > At 16:57 03/09/2014, Mirja K=FChlewind wrote: >>> >> Hi again, >>> >> >>> >> >>> >> On 28.08.2014 22:05, Bob Briscoe wrote: >>> >>>>>>>>>>>> * 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 suggestin= g >>> >>>>>>>>>>> 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, y= ou >>> >>>>>>>>> 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, t= he >>> >>>>>>> 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 ha= ve >>> >>>>> 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 pack= et >>> >>>>> 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 aud= it >>> >>>> function. This can be the case if no feedback on the congestion >>>status >>> >>>> is (currently) available for e.g. for control packets (not carryin= g >>> >>>> 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? >>> >>> The main problem is saying 'not available *for* control packets'. B= ut >>> >>> just changing 'for' to '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, given this is an >>> >>> example, so it can be specific. >>> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as >>>ACK are >>> >>> usually not 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 is (currently) >>>available >>> >>> e.g. in TCP if one endpoint has been receiving data but sending >>>nothing >>> >>> but pure ACKs (no user data) for some time. This is because pure >>>ACKs do >>> >>> not advance the sequence number, so the TCP endpoint receiving them >>> >>> cannot reliably tell whether any have been lost due to congestion. >>>Pure >>> >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >>> >> Fine for me. Done. >>> >> >>> >> >>> >>>>>> 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 wi= th >>> >>>>> 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 t= he >>> >>>> 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 an= d >>> >>>> there simply assume it will equal out. Which mean if we send a pur= e >>> >>>> 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... >>> >>> I thought the earlier definition said that ConEx accounts for the >>>size >>> >>> of the IP header that contains the CDO and everything within it. >>>Also, >>> >>> there's the TCP header size on a pure ACK. >>> >> Yes, especially when a network node accounts >>> >> ConEx marks. But in the (TCP) sender we just >>> >> don't care about the header bits for >>> >> simplification. We are aware that all bits will >>> >> be accounted but as we assume equal size packets that should be fine= . >>> >> >>> >> >>> >>> That's the basis on which I am assuming that pure ACKs are worth >>> >>> counting. A pure ACK will count as 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 be hard for TCP >>>to know >>> >>> though. >>> >> Yes, so how should I implement that? >>> > I guess just assume that any IP extensions will >>> > be constant on every packet in a flow, therefore >>> > assuming none will be similar to assuming some. >>> > >>> >>>> 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. >>> >>> Agreed (that this would affect tcp-mods, not destopt). >>> >>> >>> >>> What is 'this' that you aren't yet convinced by? >>> >> 'this' is the fact that I need to changed >>> >> something in the tcp mods document. I might >>> >> remove the statement (if existent) that control >>> >> packets should be not-ConEx capable but I would >>> >> still like to recommend it because I believe it >>> >> makes things overly complicated otherwise. The >>> >> point is I believe that at the location in the >>> >> (Linux) code where you implement the counting, >>> >> you don't even have the information how large >>> >> the pure ACK will be in the end... >>> > See next comment. >>> > >>> >>>>> 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...? >>> >>> I thought you were proposing that a TCP sender assumes all the >>>packets >>> >>> it sends are full-sized, even if they aren't. But I believe you hav= e >>> >>> said that is not what you proposed. >>> >> No, when reducing the congestion counter(s) we >>> >> use the actual number of payload bytes. We also >>> >> use the real number of acknowledged bytes to >>> >> increase the counter(s). We simply do not care >>> >> about the header bytes at all assuming that on >>> >> average all packets have the same size and >>> >> therefor the number of (marked) header bytes >>> >> (either ECN or ConEx) in total will be about right. >>> > OK. I understand now. >>> > >>> > Ultimately TCP has to put a number in the Data >>> > Offset field, so it has to know the size of its >>> > own header. However, for an initial >>> > (experimental) implementation, if you need your >>> > proposal to assume all TCP options within one >>> > flow are the same size, it would be reasonable >>> > (it's not actually true, e.g. SACK, but there >>> > should at least be no bias, so you will overstate as much as >>>understate). >>> > >>> > You say earlier that it is too complicated to >>> > implement code within TCP that knows the size of >>> > a pure ACK. If TCP code doesn't know the size of >>> > a TCP header, then Linux must be using magic >>> > instead of code. Because, surely, the whole point >>> > of the TCP code is to write a TCP header. >>> > >>> >>>>>>>>>>>> =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. traffic management = or >>> >>>> multipath routing where general forwarding nodes need to access th= is >>> >>>> information. >>> >>>> >>> >>>> So what's the solution here? >>> >>> I think this will get thrown back by the IESG if we say 'MUST be >>>first'. >>> >>> And I think 'SHOULD be first' is a doable implementation for >>>ConEx-aware >>> >>> nodes. That is sufficient for experimental. Any experiments where >>> >>> general forwarding nodes access ConEx will already be reading a >>>destopt >>> >>> at every hop, which is not what was intended, but it would be doabl= e >>> >>> just for an experiment that wanted to prove ConEx has wider uses. >>> >> I know that this might be a problem with IESG review, but... it's >>>broken... >>> >> >>> >>> Everyone involved in IPv6 knows that the attempt to design >>>extensibility >>> >>> into v6 failed. It won't be news to the IESG that we can't add an >>> >>> extension that can be processed at every hop on the fast path. >>> >>> >>> >>> If a destopt is sufficient to prove ConEx useful, then >>>implementers will >>> >>> want to satisfy this demand. Then >>> >>> * either there is even more pressure on the IETF to address this >>>failing >>> >>> in v6 (and maybe someone will), >>> >>> * or ConEx has to continue with this destopt solution, just like >>> >>> everyone else is finding hacks round this failing in v6. >>> >>> >>> >>> But don't ask me. Ask Suresh. >>> >> Yes! Unfortunately he did not response until >>> >> now. Maybe he is/was on holidays; will ping him again. >>> >> >>> >> >>> >>>>>>> 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 th= is >>> >>>>> 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 E= SP >>> >>>>> header, it generally may be desirable to place the destinatio= n >>> >>>>> 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? >>> >>> * How to do ConEx when IPsec is also required (tunnel & transport >>>modes, >>> >>> and what to count). This may all be obvious now, but (IMO) it >>>would still >>> >>> be worth spelling out obvious things. >>> >>> * How to use IPsec to protect the integrity of CDO. >>> >> Okay, this is the text now: >>> >> >>> >> "Compatibility with use of IPsec >>> >> >>> >> In IPv6 there are two possible position of a >>> >> Destination Option header, either before the >>> >> Routing header or after the Encapsulating Security Payload (ESP) >>>header. >>> > BETTER?: >>> > In IPv6 a Destination Option header can be placed >>> > in two possible position in the order of possible >>> > headers, either before the Routing header or >>> > after the Encapsulating Security Payload (ESP) header. >>> > REASONING: >>> > We are talking about the positions where these >>> > headers /would/ be if they were there - they might not actually be >>>present. >>> > >>> >> If the packet is encrypted using IPSec tunnel >>> >> mode, the CDO MUST be placed in the destination >>> >> option before the Routing header such that it >>> >> does not get encrypted and can be read by immediate ConEx-aware node= s. >>> > BETTER?: >>> > CDO MUST always be placed in a destination option >>> > header placed before where the routing header >>> > would be. Otherwise, if CDO were placed in the >>> > latter position and an ESP header were used, the CDO would be >>>encrypt the >>> > REASONING: >>> > (There is no need for it to ever be in the later >>> > position and it's best to always be in the same place.) >>> > >>> > >>> >> Note as the Authentication Header (AH) also only >>> >> protects fields after the AH header, the CDO is not authenticated >>>in this case. >>> > Need to say the encapsulator copies CDO from the >>> > inner IPv6 CDO before encrypting the inner. >>> > >>> > s/read by immediate/read by/ >>> > >>> > AH integrity protects the IPv6 header that encapsulates it. ESP does >>>not. >>> > >>> > >>> >> In IPSec transport mode both destination option >>> >> headers can be used, as the CDO is in both cases >>> >> visible to the network. If the transport network >>> >> can not be trusted, the Destination Option >>> >> header after the ESP header SHOULD be used to >>> >> ensure integrity of the ConEx information. If an >>> >> attacker would be able to remove the ConEx >>> >> marks, this could cause an audit device >>> >> to penalize the respective connection, while the >>> >> sender cannot easily detect that ConEx information is missing." >>> >> >>> >> Does this seem to be right now? >>> > Sorry, this is all wrong. One cannot use ESP to >>> > authenticate or protect the integrity of CDO by >>> > putting CDO after ESP, because ESP would then >>> > encrypt CDO so ConEx-aware nodes would not be >>> > able to read it. CDO always has to precede ESP, >>> > which is why I said CDO MUST always be in the first destopt position. >>> > >>> > If the CDO header needs to be authenticated, AH >>> > can be used as in the second example below. AH >>> > protects the integrity of the whole IPv6 datagram >>> > it is encapsulated by (except non-predictable >>> > mutable fields). AH coverage includes the IPv6 >>> > header and extension headers before the AH >>> > header, and everything after the AH header too. >Sorry that's my fault; I thought, (similar to >ESP) the authentication header would only >authenticate headers after the AH. (Checked now with rfc4302 that I was wr= ong.) > >>> > >>> > I think it would be worth listing the two or >>> > three example header sequences in the draft, as >>> > below. Headers in [] need not be present. Headers in {} are encrypted= . >>> > >>> > Transport mode without the integrity of CDO protected: >>> > IPv6 >>> > [Hop-by-Hop] >>> > [Routing] >>> > Destopt(CDO[,...]) >>> > [Fragment] >>> > ESP{ >>> > [Destopt] >>> > Upper-Layer >>> > } >>> > >>> > Transport mode with the integrity of CDO protected: >>> > IPv6 >>> > [Hop-by-Hop] >>> > [Routing] >>> > Destopt(CDO[,...]) >>> > [Fragment] >>> > AH >>> > ESP{ >>> > [Destopt] >>> > Upper-Layer >>> > } >>> > >>> > >>> > Tunnel mode: >>> > IPv6 >>> > [Hop-by-Hop] >>> > [Routing] >>> > Destopt(CDO-copy[,...]) >>> > [Fragment] >>> > ESP{ >>> > IPv6 >>> > Destopt(CDO[,...]) >>> > Transport Payload >>> > } >>> > >>> > For ESP in tunnel mode, as already stated in the >>> > draft, the tunnel ingress MUST copy the CDO from >>> > the destopt in the inner, then write a copy of >>> > the CDO header into a destopt header in the outer. >>> > >>> > I think this updates RFC2406. However, it is >>> > possible that 2406 already requires an ESP >>> > ingress to copy any extension headers, up to and >>> > including Fragmentation, to the outer. Because >>> > all these headers are designed to be visible to >>> > nodes on the path. Suresh may know this. >> >>I checked overnight and copying extension headers is contrary to the >>IPSec architecture. >> >> "IPv6 -- Header >>Construction for Tunnel Mode" says: >> "Extension headers never copied" >> >>On reflection, I don't think we should update RFC2401 for ConEx. If I >>were on the IESG, I would not approve that. IPsec needs to have simple >>rules without exceptions. >> >>When we chose destopt as the mechanism for ConEx, we knew it wasn't >>going to interact well with tunnels. I think the best approach is to say, >> "Currently, the IPv6 protocol architecture does not provide a >>mechanism for new extension headers to be copied to the outer. Therefore >>ConEx functions will have to search for the CDO option within inner >>headers, and ConEx will not work at all over the extent of an ESP tunnel"= . > >So all in all, this simplifies thing to >basically "CDO MUST be placed in the destination >option header before the AH and/or EPS (if present)." > >(+ our text just above on not interacting with tunnel mode) > >Right? > >Mirja > >> >> >>Bob >> >> >>> > >>> > To protect the integrity of the outer IPv6 >>> > datagram, including protecting the copy of CDO, >>> > an AH header (not shown) could be added before ESP. >>> > >>> > [A worse alternative (no need to mention this): >>> > If the integrity of CDO but not other headers >>> > needed to be protected, ESP with authentication >>> > enabled could be used, which causes >>> > authentication data to be added at the end of the >>> > payload (not shown). Then, before decapsulation, >>> > the tunnel egress would have to record the value >>> > of CDO-copy. Having decrypted the inner, it could >>> > then check that CDO-copy matched the CDO in the >>> > inner. However, that would require another >>> > update to RFC2406, so using AH would be >>> > preferable, given we don't want to make ConEx >>> > depend on updating both ends of an ESP tunnel - one end is bad enough= .] >>> > >>> > HTH >>> > Sorry for taking so long - I wrote most of this >>> > on a plane on Thu, but left some fact checking >>> > for when I got online, and this is the first chance I've had to get >>>back to it. >>> > >>> > Cheers >>> > >>> > >>> > >>> > Bob >>> > >>> >>>>>>>>> Moreover, isn't this here the same case than with tunneling i= n >>> >>>>>>>>> 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 somethin= g >>> >>>>>>>>> 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 n= ot >>> >>>> 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 tunnelin= g. >>> >>>> This trades off the performance of ConEx functions against that of >>> >>>> tunnel processing. " >>> >>> OK. Rather than implying that equipment has evolved conscious >>>awareness, >>> >>> a better formulation would be something like: >>> >>> "..the configuration of the tunnel ingress and the ConEx nodes is >>> >>> co-ordinated." >>> >>> >>> >>> Nits: >>> >>> s/SHOULD not/SHOULD NOT/ >>> >>> s/accounted/counted/ >>> >>> (in English, accounted is not a transitive verb, it has to have >>>'for' >>> >>> after it) >>> >>> s/ingree/ingress/ >>> >>> s/theses/these/ >>> >> Done. >>> >> >>> >> >>> >>> We're getting there! >>> >> Yes...! >>> >> >>> >> Mirja >>> >> >>> >> >>> >>> 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 thi= nk >>> >>>>>>>>>> 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 mar= ks >>> >>>>>>>>>> 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 doe= s >>> >>>>>>>>>> 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, B= T >>> >>>>>> -- >>> >>>>>> ------------------------------------------ >>> >>>>>> 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 >>> > >>> > >> >>________________________________________________________________ >>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 --_000_E87B771635882B4BA20096B589152EF6288300FDeusaamb107erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bob/Mirja,
Sounds fine to me as well. I can live with any value of X but the only one = that really makes sense is 1 :-)

Thanks
Suresh

-----Original Message-----
From: Bob Briscoe [bob.briscoe@bt.com]
Received: Tuesday, 09 Sep 2014, 1:44PM
To: Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch]
CC: Suresh Krishnan [suresh.krishnan@ericsson.com]; Carlos Ucendo [r= alli@tid.es]; ConEx IETF list [conex@ietf.org]
Subject: Re: Act bits and Positioning (Was Re: [conex] Fwd: Review: = draft-ietf-conex-destopt-06)

Mirja,

Agree with you on all 3 new responses:
* act bits =3D 00
* CDO SHOULD be first destopt, and MUST be among
the first X destopts: that works for me.
    X=3D3?
* CDO is always in the destopt position before
any IPsec, and ConEx doesn't work within an ESP tunnel.


Bob

At 15:19 09/09/2014, Mirja K=FChlewind wrote:
>Hi,
>
>see inline
>
>On 09.09.2014 09:59, Bob Briscoe wrote:
>>Suresh,
>>
>>At 05:36 09/09/2014, Suresh Krishnan wrote:
>>>Hi Bob,
>>>   Thanks a lot for your comments. I will respond to = two specific issues
>>>that you brought up
>>>
>>>act bits being 01: Please note that the Conex option is a *dest= ination*
>>>option. Non conex-aware nodes on path will not even process the= option.
>>>So we do not need to be worried about the packet being dropped = by
>>>intermediate nodes, and we need to know if the destination does= not
>>>understand it. Hence I think this should stay as 01.
>>
>>I was aware that the act bits are only processed by the destination= .
>>
>>My point was that ConEx only requires sender support (ie. you can h= ave
>>ConEx on one half-connection but not the other - there is no need t= o
>>negotiate ConEx for a connection). So it would be very bad for a >>destination to drop a packet just before delivering it to the
>>destination process just because it doesn't recognise a ConEx heade= r
>>that it doesn't need to understand anyway.
>>
>>Note to Mirja: Given this misunderstanding, perhaps the draft shoul= d
>>give a reason:
>>          "The ac= t bits MUST be 00, because a ConEx packet needs to be
>>passed to the destination process even if the destination does not<= br> >>understand ConEx."
>I agree with Bob, as the receiver does not need
>to proceed the option in our case at all and it
>does even know if it has to be there. Suresh?
>
>>
>>
>>>CDO as the first option: As you rightly note, this is just a pe= rformance
>>>optimization. I do believe that the performance penalty for con= ex-aware
>>>nodes will be pretty severe if they need to process all destina= tion
>>>options before deciding if the CDO is present or not.
>>
>>Surely a ConEx node can stop when it gets to the CDO option (which = will
>>usually be first). It doesn't need to continue and process all the = other
>>options within the destopt header.
>>
>>>Please note that
>>>this needs to be done on *all* packets passing through the cone= x aware
>>>node.
>>
>>On packets without a destopt that is quick.
>>
>>The really bad case is for packets from senders that don't support = ConEx
>>but are using many other destopts. Then the on-path ConEx node woul= d
>>walk along every destopt until the end.
>>
>>>I do think it is OK to change the MUST to a SHOULD but with a >>>severe warning.
>>
>>OK, thanks.
>>
>>Would it be OK to say "As an optimization, a ConEx implementat= ion MAY
>>limit the depth of its search for CDO to two or three destination o= ptions"?
>My assumption was that search for the CDO if
>multiple options are present is not feasible in fast path.
>
>So if the CDO is not first, there are two options:
>1) forward the packet to slow path
>2) ignore the CDO
>
>Actually case 1) is probably no option because
>this would forward all present traffic to slow
>path because none of the traffic has a CDO at all.
>
>2) is at least not feasible for something like a
>policer that really needs to look at all ConEx-enable packets.
>
>Limiting the search depth, would translate into
>"the CDO SHOULD be the first option and MUST be
>among the first X options"... is that a solution?
>
>
>Bob, see further below...
>
>>
>>
>>I have also added to my response to Mirja below, with an extra thou= ght
>>about ESP tunnels (inline - search for 'ESP tunnel' - it's a long w= ay
>>down!)...
>>
>>
>>>Cheers
>>>Suresh
>>>
>>>On 09/08/2014 06:17 PM, Bob Briscoe wrote:
>>> > Mirja,
>>> >
>>> > At 16:57 03/09/2014, Mirja K=FChlewind wrote:
>>> >> Hi again,
>>> >>
>>> >>
>>> >> On 28.08.2014 22:05, Bob Briscoe wrote:
>>> >>>>>>>>>>>> * Suggested d= eleting example of Not-ConEx-capable packets
>>>(see
>>> >>>>>>>>>>>> separate thre= ad 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 impl= y 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 th= e comment bubbles:
>>> >>>>>>>>>> "The only need I= can see for the X-flag is if
>>> >>>>>>>>>> the Reserved field ge= ts used in future for
>>> >>>>>>>>>> something in addition= to ConEx. Then there
>>> >>>>>>>>>> would be a need to id= entify packets that
>>> >>>>>>>>>> are not ConEx-capable= but still carry the
>>> >>>>>>>>>> CDO option (for the n= ew 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 do= n'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 estimatio= n of the current congestion level, you
>>> >>>>>>>>> might
>>> >>>>>>>>> underestimate it.
>>> >>>>>>>>>
>>> >>>>>>>>> Doesn't that make sense..= .?
>>> >>>>>>> Not to me. What does "feedba= ck 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 h= as feedback about that path, the
>>> >>>>>>> feedback applies to everything se= nt over the path, at the IP
>>>layer,
>>> >>>>>>> whatever categorisation the next = packet has at L4.
>>> >>>>>> If you do not get any feedback on a p= ath, 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 Con= Ex-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 m= arkings 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 usuall= y an app (let alone the
>>> >>>>> transport layer) cannot predict whether t= here will be more data
>>>to send
>>> >>>>> later, even if it's not sending any now.<= br> >>> >>>>>
>>> >>>>> 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-enable= d 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 o= ne 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 wit= h whether feedback has
>>>recently
>>> >>>>> been received.
>>> >>>> Okay, rewrote the paragraph slightly:
>>> >>>>
>>> >>>> "If the X bit is zero all other three bi= ts are undefined and thus
>>> >>>> should be ignored and forwarded unchanged by = network nodes. The X
>>>bit
>>> >>>> set to zero means that the connection is ConE= x-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 informatio= n about ACKs are not
>>> >>>> available."
>>> >>>>
>>> >>>> Is this okay?
>>> >>> The main problem is saying 'not available *for* c= ontrol packets'. But
>>> >>> just changing 'for' to 'from' would still make th= is 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, = given this is an
>>> >>> example, so it can be specific.
>>> >>> * Nit: duplicated word (for e.g. for) and duplica= ted phrase (as
>>>ACK are
>>> >>> usually not ECN-capable as ACK usually are not EC= N-capable).
>>> >>>
>>> >>> How about:
>>> >>>
>>> >>> First 2 sentences unchanged, then...
>>> >>> "This can be the case if no congestion feedb= ack is (currently)
>>>available
>>> >>> e.g. in TCP if one endpoint has been receiving da= ta but sending
>>>nothing
>>> >>> but pure ACKs (no user data) for some time. This = is because pure
>>>ACKs do
>>> >>> not advance the sequence number, so the TCP endpo= int receiving them
>>> >>> cannot reliably tell whether any have been lost d= ue to congestion.
>>>Pure
>>> >>> TCP ACKs cannot be ECN-marked either [RFC3168].&q= uot;
>>> >> Fine for me. Done.
>>> >>
>>> >>
>>> >>>>>> Further note, in the TCP mods we only= look at the payload
>>>because we
>>> >>>>>> assume, for simplification, all packe= ts have the same size.
>>>Therefore
>>> >>>>>> a packet that carries no data would n= ot 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 tc= p-mods if its 'not right'.
>>> >>>>>
>>> >>>>> I hope you see the problem from my explan= ation above - whether
>>>there is
>>> >>>>> enough feedback /now/ to ConEx-mark a pac= ket has nothing to do with
>>> >>>>> whether the packet being sent /now/ is ca= pable of generating
>>>feedback
>>> >>>>> /in the next round/.
>>> >>>>>
>>> >>>>> If you want to make a simplifying assumpt= ion, it is on the safe
>>>side for
>>> >>>>> a sender to assume that all incoming feed= back 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 kno= ws 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 ta= king this assumption be
>>> >>>> simply do not account for headers at all (nor= incoming neither
>>> >>>> outcoming) because we can anyway just estimat= ed 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 mak= es thing much
>>>simpler and
>>> >>>> is therefore useful but will not allow for ma= rking pure ACKs...
>>> >>> I thought the earlier definition said that ConEx = accounts for the
>>>size
>>> >>> of the IP header that contains the CDO and everyt= hing within it.
>>>Also,
>>> >>> there's the TCP header size on a pure ACK.
>>> >> Yes, especially when a network node accounts
>>> >> ConEx marks. But in the (TCP) sender we just
>>> >> don't care about the header bits for
>>> >> simplification. We are aware that all bits will
>>> >> be accounted but as we assume equal size packets that= should be fine.
>>> >>
>>> >>
>>> >>> That's the basis on which I am assuming that pure= ACKs are worth
>>> >>> counting. A pure ACK will count as 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 = be hard for TCP
>>>to know
>>> >>> though.
>>> >> Yes, so how should I implement that?
>>> > I guess just assume that any IP extensions will
>>> > be constant on every packet in a flow, therefore
>>> > assuming none will be similar to assuming some.
>>> >
>>> >>>> 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.
>>> >>> Agreed (that this would affect tcp-mods, not dest= opt).
>>> >>>
>>> >>> What is 'this' that you aren't yet convinced by?<= br> >>> >> 'this' is the fact that I need to changed
>>> >> something in the tcp mods document. I might
>>> >> remove the statement (if existent) that control
>>> >> packets should be not-ConEx capable but I would
>>> >> still like to recommend it because I believe it
>>> >> makes things overly complicated otherwise. The
>>> >> point is I believe that at the location in the
>>> >> (Linux) code where you implement the counting,
>>> >> you don't even have the information how large
>>> >> the pure ACK will be in the end...
>>> > See next comment.
>>> >
>>> >>>>> The simplification I propose (that feedba= ck 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 doe= sn't get loss or ECN
>>>info about
>>> >>>>> pure ACKs, so they are automatically remo= ved from the set of
>>>packets
>>> >>>>> that the sender assumes to be the same si= ze. And, and if some of
>>>the
>>> >>>>> feedback is about smaller data packets, a= t least this
>>>simplification
>>> >>>>> will always be on the safe side.
>>> >>>>>
>>> >>>>> If I correctly understand the simplificat= ion 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 differ= ent understanding of
>>>what
>>> >>>> we proposed or can you explain further...? >>> >>> I thought you were proposing that a TCP sender as= sumes all the
>>>packets
>>> >>> it sends are full-sized, even if they aren't. But= I believe you have
>>> >>> said that is not what you proposed.
>>> >> No, when reducing the congestion counter(s) we
>>> >> use the actual number of payload bytes. We also
>>> >> use the real number of acknowledged bytes to
>>> >> increase the counter(s). We simply do not care
>>> >> about the header bytes at all assuming that on
>>> >> average all packets have the same size and
>>> >> therefor the number of (marked) header bytes
>>> >> (either ECN or ConEx) in total will be about right. >>> > OK. I understand now.
>>> >
>>> > Ultimately TCP has to put a number in the Data
>>> > Offset field, so it has to know the size of its
>>> > own header. However, for an initial
>>> > (experimental) implementation, if you need your
>>> > proposal to assume all TCP options within one
>>> > flow are the same size, it would be reasonable
>>> > (it's not actually true, e.g. SACK, but there
>>> > should at least be no bias, so you will overstate as much= as
>>>understate).
>>> >
>>> > You say earlier that it is too complicated to
>>> > implement code within TCP that knows the size of
>>> > a pure ACK. If TCP code doesn't know the size of
>>> > a TCP header, then Linux must be using magic
>>> > instead of code. Because, surely, the whole point
>>> > of the TCP code is to write a TCP header.
>>> >
>>> >>>>>>>>>>>> =3D=3DFast-pa= th=3D=3D
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> * CDO as firs= t destination option: changed from MUST to
>>>SHOULD
>>> >>>>>>>>>>>> (with
>>> >>>>>>>>>>>> an example of= when not to).
>>> >>>>>>>>>>> I believe this re= ally 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 implem= ented the suggested way in the fast path.
>>> >>>>>>>>>> A SHOULD still means = it will be the first option in all
>>>current
>>> >>>>>>>>>> implementations. Howe= ver, I suggest a SHOULD, precisely
>>>because
>>> >>>>>>>>>> performance reasons a= re not absolute, so they don't require a
>>> >>>>>>>>>> MUST. If
>>> >>>>>>>>>> another dest opt cann= ot 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 (rightl= y) be very wary of any draft that says an
>>> >>>>>>>>>> option
>>> >>>>>>>>>> MUST be the first opt= ion.
>>> >>>>>>>>>>
>>> >>>>>>>>>> I suggested the follo= wing text after this: "(This is not
>>> >>>>>>>>>> stated as a 'MUST', b= ecause some future destination option
>>>might
>>> >>>>>>>>>> need to
>>> >>>>>>>>>> be placed first for f= unctional rather than just performance
>>> >>>>>>>>>> reasons.)"
>>> >>>>>>>>> So our fast path implemen= tation 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 mu= ch 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 l= ooking at one bit at a
>>>defined
>>> >>>>>> position or having a chain of conditi= onal 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 n= ot fixed anymore... that
>>>would be
>>> >>>>>> my guess but I'm not an expert in thi= s area.
>>> >>>>> AFAICT, fast path implementations general= ly work along sequences of
>>> >>>>> extensions. So I don't think this is a pr= oblem. Bear in mind
>>>that we are
>>> >>>>> not asking general fast path forwarding i= mplementations to do
>>>this. Only
>>> >>>>> ConEx functions specifically written to f= ind the ConEx
>>>header.{Note 1}
>>> >>>>>
>>> >>>>> {Note 1} OK, we do suggest that general f= orwarding functions
>>>could do
>>> >>>>> DoS protection using the ConEx header. Bu= t that's stated as
>>>optional and
>>> >>>>> 'aspirational'. If such an experiment pro= ves useful, you never
>>>know,
>>> >>>>> there could be demand for ConEx to migrat= e 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 s= traightforward
>>>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 no= des need to access this
>>> >>>> information.
>>> >>>>
>>> >>>> So what's the solution here?
>>> >>> I think this will get thrown back by the IESG if = we say 'MUST be
>>>first'.
>>> >>> And I think 'SHOULD be first' is a doable impleme= ntation for
>>>ConEx-aware
>>> >>> nodes. That is sufficient for experimental. Any e= xperiments where
>>> >>> general forwarding nodes access ConEx will alread= y be reading a
>>>destopt
>>> >>> at every hop, which is not what was intended, but= it would be doable
>>> >>> just for an experiment that wanted to prove ConEx= has wider uses.
>>> >> I know that this might be a problem with IESG review,= but... it's
>>>broken...
>>> >>
>>> >>> Everyone involved in IPv6 knows that the attempt = to design
>>>extensibility
>>> >>> into v6 failed. It won't be news to the IESG that= we can't add an
>>> >>> extension that can be processed at every hop on t= he fast path.
>>> >>>
>>> >>> If a destopt is sufficient to prove ConEx useful,= then
>>>implementers will
>>> >>> want to satisfy this demand. Then
>>> >>> * either there is even more pressure on the IETF = to address this
>>>failing
>>> >>> in v6 (and maybe someone will),
>>> >>> * or ConEx has to continue with this destopt solu= tion, just like
>>> >>> everyone else is finding hacks round this failing= in v6.
>>> >>>
>>> >>> But don't ask me. Ask Suresh.
>>> >> Yes! Unfortunately he did not response until
>>> >> now. Maybe he is/was on holidays; will ping him again= .
>>> >>
>>> >>
>>> >>>>>>> Then "CDO SHOULD be first&qu= ot; would give no different performance
>>>to "CDO
>>> >>>>>>> MUST be first", if CDO actua= lly 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 fi= rst".
>>> >>>>>>>
>>> >>>>>>> Note: I've just re-read the spec = of the IPv6 header. We need to
>>> >>>>>>> specify
>>> >>>>>>> that CDO goes in the "Destin= ation Options (before routing
>>>header)",
>>> >>>>>>> not
>>> >>>>>>> the "Destination Options (be= fore 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 li= sted in the routing header
>>>should
>>> >>>>>> proceed this option or not. In our ca= se it is probably not
>>>important
>>> >>>>>> which one we choose as it should be p= rocessed by none of the
>>>receivers.
>>> >>>>> You're correct that CDO isn't processed b= y any of the nodes
>>>listed in
>>> >>>>> the routing header as destinations. The p= hrase "before routing
>>>header"
>>> >>>>> is just how its placement is described. W= e 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 hea= der, and it comes just
>>>before
>>> >>>>> the second dest opts. So it would be no g= ood putting CDO after it.
>>> >>>>>
>>> >>>>> See the ESP spec, on "ESP Header Loc= ation":
>>> >>>>> <http://tools.ietf.org/html/rfc2406#section-3.1>= ;
>>> >>>>> "  The destination options exte= nsion header(s) could appear
>>> >>>>>     either before or = after the ESP header depending on the
>>>semantics
>>> >>>>>     desired.  Ho= wever, since ESP protects only fields after the ESP
>>> >>>>>     header, it genera= lly 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":
>>> >>>>> <http://tools.ietf.org/html/rfc2460#section-4.1>= ;
>>> >>>>>
>>> >>>>> I believe one reason there are two places= for the dest opt is
>>>because if
>>> >>>>> ESP is encrypting everything for the dest= ination, it will
>>>normally be
>>> >>>>> expected that the dest opts need to be en= crypted 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 ke= y).  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 d= estination option before routing
>>> >>>>>> header such that it does not get encr= ypted and can be read by
>>> >>>>>> immediate ConEx-aware nodes." >>> >>>>>> And then remove the first paragraph o= f the IPSec section (and
>>>probably
>>> >>>>>> move the other paragraph somewhere el= se so that the section is
>>>removed
>>> >>>>>> completely)...?
>>> >>>>> I've lost track of all the proposed chang= es to the IPsec
>>>section. But I
>>> >>>>> think there is value in spelling out exac= tly how ConEx and IPsec
>>> >>>>> interact, so I wouldn't remove the sectio= n 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 opt= ion 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?
>>> >>> * How to do ConEx when IPsec is also required (tu= nnel & transport
>>>modes,
>>> >>> and what to count). This may all be obvious now, = but (IMO) it
>>>would still
>>> >>> be worth spelling out obvious things.
>>> >>> * How to use IPsec to protect the integrity of CD= O.
>>> >> Okay, this is the text now:
>>> >>
>>> >> "Compatibility with use of IPsec
>>> >>
>>> >> In IPv6 there are two possible position of a
>>> >> Destination Option header, either before the
>>> >> Routing header or after the Encapsulating Security Pa= yload (ESP)
>>>header.
>>> >          BET= TER?:
>>> > In IPv6 a Destination Option header can be placed
>>> > in two possible position in the order of possible
>>> > headers, either before the Routing header or
>>> > after the Encapsulating Security Payload (ESP) header. >>> >          REA= SONING:
>>> > We are talking about the positions where these
>>> > headers /would/ be if they were there - they might not ac= tually be
>>>present.
>>> >
>>> >> If the packet is encrypted using IPSec tunnel
>>> >> mode, the CDO MUST be placed in the destination
>>> >> option before the Routing header such that it
>>> >> does not get encrypted and can be read by immediate C= onEx-aware nodes.
>>> >          BET= TER?:
>>> > CDO MUST always be placed in a destination option
>>> > header placed before where the routing header
>>> > would be. Otherwise, if CDO were placed in the
>>> > latter position and an ESP header were used, the CDO woul= d be
>>>encrypt the
>>> >          REA= SONING:
>>> > (There is no need for it to ever be in the later
>>> > position and it's best to always be in the same place.) >>> >
>>> >
>>> >> Note as the Authentication Header (AH) also only
>>> >> protects fields after the AH header, the CDO is not a= uthenticated
>>>in this case.
>>> > Need to say the encapsulator copies CDO from the
>>> > inner IPv6 CDO before encrypting the inner.
>>> >
>>> > s/read by immediate/read by/
>>> >
>>> > AH integrity protects the IPv6 header that encapsulates i= t. ESP does
>>>not.
>>> >
>>> >
>>> >> In IPSec transport mode both destination option
>>> >> headers can be used, as the CDO is in both cases
>>> >> visible to the network. If the transport network
>>> >> can not be trusted, the Destination Option
>>> >> header after the ESP header SHOULD be used to
>>> >> ensure integrity of the ConEx information. If an
>>> >> attacker would be able to remove the ConEx
>>> >> marks, this could      =   cause an audit device
>>> >> to penalize the respective connection, while the
>>> >> sender cannot easily detect that ConEx information is= missing."
>>> >>
>>> >> Does this seem to be right now?
>>> > Sorry, this is all wrong. One cannot use ESP to
>>> > authenticate or protect the integrity of CDO by
>>> > putting CDO after ESP, because ESP would then
>>> > encrypt CDO so ConEx-aware nodes would not be
>>> > able to read it. CDO always has to precede ESP,
>>> > which is why I said CDO MUST always be in the first desto= pt position.
>>> >
>>> > If the CDO header needs to be authenticated, AH
>>> > can be used as in the second example below. AH
>>> > protects the integrity of the whole IPv6 datagram
>>> > it is encapsulated by (except non-predictable
>>> > mutable fields). AH coverage includes the IPv6
>>> > header and extension headers before the AH
>>> > header, and everything after the AH header too.
>Sorry that's my fault; I thought, (similar to
>ESP) the authentication header would only
>authenticate headers after the AH. (Checked now with rfc4302 that I was= wrong.)
>
>>> >
>>> > I think it would be worth listing the two or
>>> > three example header sequences in the draft, as
>>> > below. Headers in [] need not be present. Headers in {} a= re encrypted.
>>> >
>>> > Transport mode without the integrity of CDO protected: >>> >    IPv6
>>> >    [Hop-by-Hop]
>>> >    [Routing]
>>> >    Destopt(CDO[,...])
>>> >    [Fragment]
>>> >    ESP{
>>> >      [Destopt]
>>> >      Upper-Layer
>>> >    }
>>> >
>>> > Transport mode with the integrity of CDO protected:
>>> >    IPv6
>>> >    [Hop-by-Hop]
>>> >    [Routing]
>>> >    Destopt(CDO[,...])
>>> >    [Fragment]
>>> >    AH
>>> >    ESP{
>>> >      [Destopt]
>>> >      Upper-Layer
>>> >    }
>>> >
>>> >
>>> > Tunnel mode:
>>> >    IPv6
>>> >    [Hop-by-Hop]
>>> >    [Routing]
>>> >    Destopt(CDO-copy[,...])
>>> >    [Fragment]
>>> >    ESP{
>>> >      IPv6
>>> >      Destopt(CDO[,...])
>>> >      Transport Payload
>>> >    }
>>> >
>>> > For ESP in tunnel mode, as already stated in the
>>> > draft, the tunnel ingress MUST copy the CDO from
>>> > the destopt in the inner, then write a copy of
>>> > the CDO header into a destopt header in the outer.
>>> >
>>> > I think this updates RFC2406. However, it is
>>> > possible that 2406 already requires an ESP
>>> > ingress to copy any extension headers, up to and
>>> > including Fragmentation, to the outer. Because
>>> > all these headers are designed to be visible to
>>> > nodes on the path. Suresh may know this.
>>
>>I checked overnight and copying extension headers is contrary to th= e
>>IPSec architecture.
>>
>><= http://tools.ietf.org/html/rfc2401#section-5.1.2.2> "IPv6 -- He= ader
>>Construction for Tunnel Mode" says:
>>          "Extens= ion headers  never copied"
>>
>>On reflection, I don't think we should update RFC2401 for ConEx. If= I
>>were on the IESG, I would not approve that. IPsec needs to have sim= ple
>>rules without exceptions.
>>
>>When we chose destopt as the mechanism for ConEx, we knew it wasn't=
>>going to interact well with tunnels. I think the best approach is t= o say,
>>          "Curren= tly, the IPv6 protocol architecture does not provide a
>>mechanism for new extension headers to be copied to the outer. Ther= efore
>>ConEx functions will have to search for the CDO option within inner=
>>headers, and ConEx will not work at all over the extent of an ESP t= unnel".
>
>So all in all, this simplifies thing to
>basically "CDO MUST be placed in the destination
>option header before the AH and/or EPS (if present)."
>
>(+ our text just above on not interacting with tunnel mode)
>
>Right?
>
>Mirja
>
>>
>>
>>Bob
>>
>>
>>> >
>>> > To protect the integrity of the outer IPv6
>>> > datagram, including protecting the copy of CDO,
>>> > an AH header (not shown) could be added before ESP.
>>> >
>>> > [A worse alternative (no need to mention this):
>>> > If the integrity of CDO but not other headers
>>> > needed to be protected, ESP with authentication
>>> > enabled could be used, which causes
>>> > authentication data to be added at the end of the
>>> > payload (not shown). Then, before decapsulation,
>>> > the tunnel egress would have to record the value
>>> > of CDO-copy. Having decrypted the inner, it could
>>> > then check that CDO-copy matched the CDO in the
>>> > inner.  However, that would require another
>>> > update to RFC2406, so using AH would be
>>> > preferable, given we don't want to make ConEx
>>> > depend on updating both ends of an ESP tunnel - one end i= s bad enough.]
>>> >
>>> > HTH
>>> > Sorry for taking so long - I wrote most of this
>>> > on a plane on Thu, but left some fact checking
>>> > for when I got online, and this is the first chance I've = had to get
>>>back to it.
>>> >
>>> > Cheers
>>> >
>>> >
>>> >
>>> > Bob
>>> >
>>> >>>>>>>>> Moreover, isn't this here= the same case than with tunneling in
>>> >>>>>>>>> general.
>>> >>>>>>>>> Only if the node that doe= s the encapsulation is ConEx-aware
>>>it can
>>> >>>>>>>>> copy
>>> >>>>>>>>> the CDO, otherwise it wil= l be not visible anymore.
>>> >>>>>>>>>
>>> >>>>>>>>> So this should either be = a should, or we have to say something
>>> >>>>>>>>> like: if
>>> >>>>>>>>> the node is ConEx-aware i= s MUST copy the CDO...?
>>> >>>>>>>> And then we can the same thin= g for tunneling in general...?
>>> >>>>>>> That's surely a circular argument= . What would make a tunnel
>>>endpoint
>>> >>>>>>> into a ConEx-aware tunnel endpoin= t, so that it would have to
>>>copy the
>>> >>>>>>> CDO? It would only become ConEx-a= ware if it had code added to
>>>look for
>>> >>>>>>> the CDO, and why would it have th= at 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 t= he node does not know
>>>anything
>>> >>>>>> about ConEx, it simple cannot copy th= e option, which is the
>>>case for
>>> >>>>>> all currently existent nodes. So we c= annot 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 i= s a little pathologic. I'm
>>>will
>>> >>>>>> to change if that helps understanding= /is less confusing.
>>> >>>>> I think we're talking past each other. Gi= ven 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 Con= Ex. 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 c= lear, not sure if I
>>> >>>> succeeded:
>>> >>>> "As with any destination option, an ingr= ess tunnel endpoint will not
>>> >>>> natively copy the CDO when adding an encapsul= ating 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 tha= t would be accounted.
>>> >>>> However, it MAY copy the CDO to the outer in = order to facilitate
>>> >>>> visibility by subsequent on-path ConEx functi= ons if the tunnel
>>>ingree
>>> >>>> is aware of these nodes and theses nodes are = aware of the tunneling.
>>> >>>> This trades off the performance of ConEx func= tions against that of
>>> >>>> tunnel processing. "
>>> >>> OK. Rather than implying that equipment has evolv= ed conscious
>>>awareness,
>>> >>> a better formulation would be something like:
>>> >>> "..the configuration of the tunnel ingress a= nd the ConEx nodes is
>>> >>> co-ordinated."
>>> >>>
>>> >>> Nits:
>>> >>> s/SHOULD not/SHOULD NOT/
>>> >>> s/accounted/counted/
>>> >>>    (in English, accounted is not a= transitive verb, it has to have
>>>'for'
>>> >>> after it)
>>> >>> s/ingree/ingress/
>>> >>> s/theses/these/
>>> >> Done.
>>> >>
>>> >>
>>> >>> We're getting there!
>>> >> Yes...!
>>> >>
>>> >> Mirja
>>> >>
>>> >>
>>> >>> But we really do need Suresh's expert eye on this= .
>>> >>>
>>> >>>
>>> >>> Cheers
>>> >>>
>>> >>>
>>> >>> Bob
>>> >>>
>>> >>>
>>> >>>> Mirja
>>> >>>>
>>> >>>>> HTH
>>> >>>>> (Delayed 'cos it was a public holday in t= he UK yesterday.)
>>> >>>>>
>>> >>>>>
>>> >>>>> Bob
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>>> Bob
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>> Mirja
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>>>>> =3D=3DSecurit= y Considerations=3D=3D
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> * Added lots,= all pointers to where security issues are
>>> >>>>>>>>>>>> discussed in<= br> >>> >>>>>>>>>>>> other places = (which is what security directorate
>>>reviewers need).
>>> >>>>>>>>>>> Okay I can add th= at if you think it's necessary (I would
>>>say it's
>>> >>>>>>>>>>> just
>>> >>>>>>>>>>> redundant, but yo= u be might right that it just helps the
>>>sec dir).
>>> >>>>>>>>>> It's not always obvio= us 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 willi= ng to be corrected.
>>> >>>>>>>>>>> I agree; Will ask= Suresh why he has put a 10 though.
>>> >>>>>>>>>> Yes, he's the right g= uy to check with.
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> Bob
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>> Thanks,
>>> >>>>>>>>>>> Mirja
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Regards
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Bob
>>> >>>>>>>>>> {Note 1}
>>> >>>>>>>>>> For anyone watching o= n the list, the tentative idea that
>>>Mirja has
>>> >>>>>>>>>> reminded me of is doc= umented 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 st= arts dropping packets because the user
>>>has
>>> >>>>>>>>>> contributed excessive= ly to congestion, in subsequent rounds
>>>the
>>> >>>>>>>>>> user
>>> >>>>>>>>>> has
>>> >>>>>>>>>> to re-echo 'L' markin= gs for the policer drops as well. This
>>>can
>>> >>>>>>>>>> drive
>>> >>>>>>>>>> the policer further i= nto 'debit'. This might make it
>>>difficult for
>>> >>>>>>>>>> the
>>> >>>>>>>>>> user to get out of tr= ouble once she's started getting into
>>>trouble.
>>> >>>>>>>>>>
>>> >>>>>>>>>> The basic idea was th= at when a congestion policer drops
>>>packets
>>> >>>>>>>>>> (because
>>> >>>>>>>>>> the user is causing m= ore 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 congesti= on drops, they are policer drops.
>>> >>>>>>>>>>
>>> >>>>>>>>>> We didn't that double= punishment made it hard to get out of
>>> >>>>>>>>>> trouble in
>>> >>>>>>>>>> any policer experimen= ts 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 e= xperimental anyway. If this problem does
>>> >>>>>>>>>> surface,
>>> >>>>>>>>>> then we can reconside= r.
>>> >>>>>>>>>>
>>>_______________________________________________________________= _
>>> >>>>>>>>>> Bob
>>>Briscoe,         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   BT
>>> >>>>>>>> --
>>> >>>>>>>> -----------------------------= -------------
>>> >>>>>>>> Dipl.-Ing. Mirja K=FChlewind<= br> >>> >>>>>>>> Communication Systems Group >>> >>>>>>>> Institute TIK, ETH Z=FCrich >>> >>>>>>>> Gloriastrasse 35, 8092 Z=FCri= ch, Switzerland
>>> >>>>>>>>
>>> >>>>>>>> Room ETZ G93
>>> >>>>>>>> phone: +41 44 63 26932 >>> >>>>>>>> email: mirja.kuehlewind@tik.e= e.ethz.ch
>>> >>>>>>>> -----------------------------= -------------
>>> >>>>>>> _________________________________= _______________________________
>>> >>>>>>> Bob Briscoe,   &nb= sp;            =             &nb= sp;            =          BT
>>> >>>>>> --
>>> >>>>>> -------------------------------------= -----
>>> >>>>>> Dipl.-Ing. Mirja K=FChlewind
>>> >>>>>> Communication Systems Group
>>> >>>>>> Institute TIK, ETH Z=FCrich
>>> >>>>>> Gloriastrasse 35, 8092 Z=FCrich, Swit= zerland
>>> >>>>>>
>>> >>>>>> Room ETZ G93
>>> >>>>>> phone: +41 44 63 26932
>>> >>>>>> email: mirja.kuehlewind@tik.ee.ethz.c= h
>>> >>>>>> -------------------------------------= -----
>>> >>>>> _________________________________________= _______________________
>>> >>>>> Bob Briscoe,     = ;            &n= bsp;            = ;            &n= bsp;       BT
>>> >>>> --
>>> >>>> ------------------------------------------ >>> >>>> Dipl.-Ing. Mirja K=FChlewind
>>> >>>> Communication Systems Group
>>> >>>> Institute TIK, ETH Z=FCrich
>>> >>>> Gloriastrasse 35, 8092 Z=FCrich, Switzerland<= br> >>> >>>>
>>> >>>> Room ETZ G93
>>> >>>> phone: +41 44 63 26932
>>> >>>> email: mirja.kuehlewind@tik.ee.ethz.ch
>>> >>>> ------------------------------------------ >>> >>> _________________________________________________= _______________
>>> >>> Bob Briscoe,      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      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,       &nb= sp;            =             &nb= sp;            =      BT
>>> >
>>> >
>>
>>________________________________________________________________ >>Bob Briscoe,         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   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,          &nb= sp;            =             &nb= sp;            =   BT

--_000_E87B771635882B4BA20096B589152EF6288300FDeusaamb107erics_-- From nobody Mon Sep 15 00:51: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 03A481A0052 for ; Mon, 15 Sep 2014 00:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 dKMnxYQWj1lB for ; Mon, 15 Sep 2014 00:51:09 -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 849D11A008D for ; Mon, 15 Sep 2014 00:51:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94748D9310; Mon, 15 Sep 2014 09:51:05 +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 fFvm7bORRixF; Mon, 15 Sep 2014 09:51:05 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f71746d.pool.mediaWays.net [95.113.116.109]) (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 B7384D930D; Mon, 15 Sep 2014 09:51:04 +0200 (MEST) Message-ID: <54169A68.30000@tik.ee.ethz.ch> Date: Mon, 15 Sep 2014 09:51:04 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Suresh Krishnan , "bob.briscoe@bt.com" 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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> <540F0C78.7050309@tik.ee.ethz.ch>, <201409091743.s89HheQJ021974@bagheera.jungle.bt.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/f6AEJbJFxobtnC-h7NlAHLUw0AA Cc: "ralli@tid.es" , "conex@ietf.org" Subject: Re: [conex] Act bits and Positioning (Was Re: 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, 15 Sep 2014 07:51:15 -0000 I also would prefer to say that the CDO MUST be first and give it a try and see what the IESG says. If there are concerns, we can still change it to MUST be among the first 3... Mirja On 12.09.2014 05:33, Suresh Krishnan wrote: > Hi Bob/Mirja, > Sounds fine to me as well. I can live with any value of X but the only > one that really makes sense is 1 :-) > > Thanks > Suresh > > -----Original Message----- > *From:* Bob Briscoe [bob.briscoe@bt.com] > *Received:* Tuesday, 09 Sep 2014, 1:44PM > *To:* Mirja Kühlewind [mirja.kuehlewind@tik.ee.ethz.ch] > *CC:* Suresh Krishnan [suresh.krishnan@ericsson.com]; Carlos Ucendo > [ralli@tid.es]; ConEx IETF list [conex@ietf.org] > *Subject:* Re: Act bits and Positioning (Was Re: [conex] Fwd: Review: > draft-ietf-conex-destopt-06) > > Mirja, > > Agree with you on all 3 new responses: > * act bits = 00 > * CDO SHOULD be first destopt, and MUST be among > the first X destopts: that works for me. > X=3? > * CDO is always in the destopt position before > any IPsec, and ConEx doesn't work within an ESP tunnel. > > > Bob > > At 15:19 09/09/2014, Mirja Kühlewind wrote: >>Hi, >> >>see inline >> >>On 09.09.2014 09:59, Bob Briscoe wrote: >>>Suresh, >>> >>>At 05:36 09/09/2014, Suresh Krishnan wrote: >>>>Hi Bob, >>>> Thanks a lot for your comments. I will respond to two specific issues >>>>that you brought up >>>> >>>>act bits being 01: Please note that the Conex option is a *destination* >>>>option. Non conex-aware nodes on path will not even process the option. >>>>So we do not need to be worried about the packet being dropped by >>>>intermediate nodes, and we need to know if the destination does not >>>>understand it. Hence I think this should stay as 01. >>> >>>I was aware that the act bits are only processed by the destination. >>> >>>My point was that ConEx only requires sender support (ie. you can have >>>ConEx on one half-connection but not the other - there is no need to >>>negotiate ConEx for a connection). So it would be very bad for a >>>destination to drop a packet just before delivering it to the >>>destination process just because it doesn't recognise a ConEx header >>>that it doesn't need to understand anyway. >>> >>>Note to Mirja: Given this misunderstanding, perhaps the draft should >>>give a reason: >>> "The act bits MUST be 00, because a ConEx packet needs to be >>>passed to the destination process even if the destination does not >>>understand ConEx." >>I agree with Bob, as the receiver does not need >>to proceed the option in our case at all and it >>does even know if it has to be there. Suresh? >> >>> >>> >>>>CDO as the first option: As you rightly note, this is just a performance >>>>optimization. I do believe that the performance penalty for conex-aware >>>>nodes will be pretty severe if they need to process all destination >>>>options before deciding if the CDO is present or not. >>> >>>Surely a ConEx node can stop when it gets to the CDO option (which will >>>usually be first). It doesn't need to continue and process all the other >>>options within the destopt header. >>> >>>>Please note that >>>>this needs to be done on *all* packets passing through the conex aware >>>>node. >>> >>>On packets without a destopt that is quick. >>> >>>The really bad case is for packets from senders that don't support ConEx >>>but are using many other destopts. Then the on-path ConEx node would >>>walk along every destopt until the end. >>> >>>>I do think it is OK to change the MUST to a SHOULD but with a >>>>severe warning. >>> >>>OK, thanks. >>> >>>Would it be OK to say "As an optimization, a ConEx implementation MAY >>>limit the depth of its search for CDO to two or three destination options"? >>My assumption was that search for the CDO if >>multiple options are present is not feasible in fast path. >> >>So if the CDO is not first, there are two options: >>1) forward the packet to slow path >>2) ignore the CDO >> >>Actually case 1) is probably no option because >>this would forward all present traffic to slow >>path because none of the traffic has a CDO at all. >> >>2) is at least not feasible for something like a >>policer that really needs to look at all ConEx-enable packets. >> >>Limiting the search depth, would translate into >>"the CDO SHOULD be the first option and MUST be >>among the first X options"... is that a solution? >> >> >>Bob, see further below... >> >>> >>> >>>I have also added to my response to Mirja below, with an extra thought >>>about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way >>>down!)... >>> >>> >>>>Cheers >>>>Suresh >>>> >>>>On 09/08/2014 06:17 PM, Bob Briscoe wrote: >>>> > Mirja, >>>> > >>>> > At 16:57 03/09/2014, Mirja Kühlewind wrote: >>>> >> Hi again, >>>> >> >>>> >> >>>> >> On 28.08.2014 22:05, Bob Briscoe wrote: >>>> >>>>>>>>>>>> * 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? >>>> >>> The main problem is saying 'not available *for* control packets'. But >>>> >>> just changing 'for' to '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, given this is an >>>> >>> example, so it can be specific. >>>> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as >>>>ACK are >>>> >>> usually not 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 is (currently) >>>>available >>>> >>> e.g. in TCP if one endpoint has been receiving data but sending >>>>nothing >>>> >>> but pure ACKs (no user data) for some time. This is because pure >>>>ACKs do >>>> >>> not advance the sequence number, so the TCP endpoint receiving them >>>> >>> cannot reliably tell whether any have been lost due to congestion. >>>>Pure >>>> >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >>>> >> Fine for me. Done. >>>> >> >>>> >> >>>> >>>>>> 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... >>>> >>> I thought the earlier definition said that ConEx accounts for the >>>>size >>>> >>> of the IP header that contains the CDO and everything within it. >>>>Also, >>>> >>> there's the TCP header size on a pure ACK. >>>> >> Yes, especially when a network node accounts >>>> >> ConEx marks. But in the (TCP) sender we just >>>> >> don't care about the header bits for >>>> >> simplification. We are aware that all bits will >>>> >> be accounted but as we assume equal size packets that should be fine. >>>> >> >>>> >> >>>> >>> That's the basis on which I am assuming that pure ACKs are worth >>>> >>> counting. A pure ACK will count as 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 be hard for TCP >>>>to know >>>> >>> though. >>>> >> Yes, so how should I implement that? >>>> > I guess just assume that any IP extensions will >>>> > be constant on every packet in a flow, therefore >>>> > assuming none will be similar to assuming some. >>>> > >>>> >>>> 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. >>>> >>> Agreed (that this would affect tcp-mods, not destopt). >>>> >>> >>>> >>> What is 'this' that you aren't yet convinced by? >>>> >> 'this' is the fact that I need to changed >>>> >> something in the tcp mods document. I might >>>> >> remove the statement (if existent) that control >>>> >> packets should be not-ConEx capable but I would >>>> >> still like to recommend it because I believe it >>>> >> makes things overly complicated otherwise. The >>>> >> point is I believe that at the location in the >>>> >> (Linux) code where you implement the counting, >>>> >> you don't even have the information how large >>>> >> the pure ACK will be in the end... >>>> > See next comment. >>>> > >>>> >>>>> 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...? >>>> >>> I thought you were proposing that a TCP sender assumes all the >>>>packets >>>> >>> it sends are full-sized, even if they aren't. But I believe you have >>>> >>> said that is not what you proposed. >>>> >> No, when reducing the congestion counter(s) we >>>> >> use the actual number of payload bytes. We also >>>> >> use the real number of acknowledged bytes to >>>> >> increase the counter(s). We simply do not care >>>> >> about the header bytes at all assuming that on >>>> >> average all packets have the same size and >>>> >> therefor the number of (marked) header bytes >>>> >> (either ECN or ConEx) in total will be about right. >>>> > OK. I understand now. >>>> > >>>> > Ultimately TCP has to put a number in the Data >>>> > Offset field, so it has to know the size of its >>>> > own header. However, for an initial >>>> > (experimental) implementation, if you need your >>>> > proposal to assume all TCP options within one >>>> > flow are the same size, it would be reasonable >>>> > (it's not actually true, e.g. SACK, but there >>>> > should at least be no bias, so you will overstate as much as >>>>understate). >>>> > >>>> > You say earlier that it is too complicated to >>>> > implement code within TCP that knows the size of >>>> > a pure ACK. If TCP code doesn't know the size of >>>> > a TCP header, then Linux must be using magic >>>> > instead of code. Because, surely, the whole point >>>> > of the TCP code is to write a TCP header. >>>> > >>>> >>>>>>>>>>>> ==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? >>>> >>> I think this will get thrown back by the IESG if we say 'MUST be >>>>first'. >>>> >>> And I think 'SHOULD be first' is a doable implementation for >>>>ConEx-aware >>>> >>> nodes. That is sufficient for experimental. Any experiments where >>>> >>> general forwarding nodes access ConEx will already be reading a >>>>destopt >>>> >>> at every hop, which is not what was intended, but it would be doable >>>> >>> just for an experiment that wanted to prove ConEx has wider uses. >>>> >> I know that this might be a problem with IESG review, but... it's >>>>broken... >>>> >> >>>> >>> Everyone involved in IPv6 knows that the attempt to design >>>>extensibility >>>> >>> into v6 failed. It won't be news to the IESG that we can't add an >>>> >>> extension that can be processed at every hop on the fast path. >>>> >>> >>>> >>> If a destopt is sufficient to prove ConEx useful, then >>>>implementers will >>>> >>> want to satisfy this demand. Then >>>> >>> * either there is even more pressure on the IETF to address this >>>>failing >>>> >>> in v6 (and maybe someone will), >>>> >>> * or ConEx has to continue with this destopt solution, just like >>>> >>> everyone else is finding hacks round this failing in v6. >>>> >>> >>>> >>> But don't ask me. Ask Suresh. >>>> >> Yes! Unfortunately he did not response until >>>> >> now. Maybe he is/was on holidays; will ping him again. >>>> >> >>>> >> >>>> >>>>>>> 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? >>>> >>> * How to do ConEx when IPsec is also required (tunnel & transport >>>>modes, >>>> >>> and what to count). This may all be obvious now, but (IMO) it >>>>would still >>>> >>> be worth spelling out obvious things. >>>> >>> * How to use IPsec to protect the integrity of CDO. >>>> >> Okay, this is the text now: >>>> >> >>>> >> "Compatibility with use of IPsec >>>> >> >>>> >> In IPv6 there are two possible position of a >>>> >> Destination Option header, either before the >>>> >> Routing header or after the Encapsulating Security Payload (ESP) >>>>header. >>>> > BETTER?: >>>> > In IPv6 a Destination Option header can be placed >>>> > in two possible position in the order of possible >>>> > headers, either before the Routing header or >>>> > after the Encapsulating Security Payload (ESP) header. >>>> > REASONING: >>>> > We are talking about the positions where these >>>> > headers /would/ be if they were there - they might not actually be >>>>present. >>>> > >>>> >> If the packet is encrypted using IPSec tunnel >>>> >> mode, the CDO MUST be placed in the destination >>>> >> option before the Routing header such that it >>>> >> does not get encrypted and can be read by immediate ConEx-aware nodes. >>>> > BETTER?: >>>> > CDO MUST always be placed in a destination option >>>> > header placed before where the routing header >>>> > would be. Otherwise, if CDO were placed in the >>>> > latter position and an ESP header were used, the CDO would be >>>>encrypt the >>>> > REASONING: >>>> > (There is no need for it to ever be in the later >>>> > position and it's best to always be in the same place.) >>>> > >>>> > >>>> >> Note as the Authentication Header (AH) also only >>>> >> protects fields after the AH header, the CDO is not authenticated >>>>in this case. >>>> > Need to say the encapsulator copies CDO from the >>>> > inner IPv6 CDO before encrypting the inner. >>>> > >>>> > s/read by immediate/read by/ >>>> > >>>> > AH integrity protects the IPv6 header that encapsulates it. ESP does >>>>not. >>>> > >>>> > >>>> >> In IPSec transport mode both destination option >>>> >> headers can be used, as the CDO is in both cases >>>> >> visible to the network. If the transport network >>>> >> can not be trusted, the Destination Option >>>> >> header after the ESP header SHOULD be used to >>>> >> ensure integrity of the ConEx information. If an >>>> >> attacker would be able to remove the ConEx >>>> >> marks, this could cause an audit device >>>> >> to penalize the respective connection, while the >>>> >> sender cannot easily detect that ConEx information is missing." >>>> >> >>>> >> Does this seem to be right now? >>>> > Sorry, this is all wrong. One cannot use ESP to >>>> > authenticate or protect the integrity of CDO by >>>> > putting CDO after ESP, because ESP would then >>>> > encrypt CDO so ConEx-aware nodes would not be >>>> > able to read it. CDO always has to precede ESP, >>>> > which is why I said CDO MUST always be in the first destopt position. >>>> > >>>> > If the CDO header needs to be authenticated, AH >>>> > can be used as in the second example below. AH >>>> > protects the integrity of the whole IPv6 datagram >>>> > it is encapsulated by (except non-predictable >>>> > mutable fields). AH coverage includes the IPv6 >>>> > header and extension headers before the AH >>>> > header, and everything after the AH header too. >>Sorry that's my fault; I thought, (similar to >>ESP) the authentication header would only >>authenticate headers after the AH. (Checked now with rfc4302 that I was wrong.) >> >>>> > >>>> > I think it would be worth listing the two or >>>> > three example header sequences in the draft, as >>>> > below. Headers in [] need not be present. Headers in {} are encrypted. >>>> > >>>> > Transport mode without the integrity of CDO protected: >>>> > IPv6 >>>> > [Hop-by-Hop] >>>> > [Routing] >>>> > Destopt(CDO[,...]) >>>> > [Fragment] >>>> > ESP{ >>>> > [Destopt] >>>> > Upper-Layer >>>> > } >>>> > >>>> > Transport mode with the integrity of CDO protected: >>>> > IPv6 >>>> > [Hop-by-Hop] >>>> > [Routing] >>>> > Destopt(CDO[,...]) >>>> > [Fragment] >>>> > AH >>>> > ESP{ >>>> > [Destopt] >>>> > Upper-Layer >>>> > } >>>> > >>>> > >>>> > Tunnel mode: >>>> > IPv6 >>>> > [Hop-by-Hop] >>>> > [Routing] >>>> > Destopt(CDO-copy[,...]) >>>> > [Fragment] >>>> > ESP{ >>>> > IPv6 >>>> > Destopt(CDO[,...]) >>>> > Transport Payload >>>> > } >>>> > >>>> > For ESP in tunnel mode, as already stated in the >>>> > draft, the tunnel ingress MUST copy the CDO from >>>> > the destopt in the inner, then write a copy of >>>> > the CDO header into a destopt header in the outer. >>>> > >>>> > I think this updates RFC2406. However, it is >>>> > possible that 2406 already requires an ESP >>>> > ingress to copy any extension headers, up to and >>>> > including Fragmentation, to the outer. Because >>>> > all these headers are designed to be visible to >>>> > nodes on the path. Suresh may know this. >>> >>>I checked overnight and copying extension headers is contrary to the >>>IPSec architecture. >>> >>> "IPv6 -- Header >>>Construction for Tunnel Mode" says: >>> "Extension headers never copied" >>> >>>On reflection, I don't think we should update RFC2401 for ConEx. If I >>>were on the IESG, I would not approve that. IPsec needs to have simple >>>rules without exceptions. >>> >>>When we chose destopt as the mechanism for ConEx, we knew it wasn't >>>going to interact well with tunnels. I think the best approach is to say, >>> "Currently, the IPv6 protocol architecture does not provide a >>>mechanism for new extension headers to be copied to the outer. Therefore >>>ConEx functions will have to search for the CDO option within inner >>>headers, and ConEx will not work at all over the extent of an ESP tunnel". >> >>So all in all, this simplifies thing to >>basically "CDO MUST be placed in the destination >>option header before the AH and/or EPS (if present)." >> >>(+ our text just above on not interacting with tunnel mode) >> >>Right? >> >>Mirja >> >>> >>> >>>Bob >>> >>> >>>> > >>>> > To protect the integrity of the outer IPv6 >>>> > datagram, including protecting the copy of CDO, >>>> > an AH header (not shown) could be added before ESP. >>>> > >>>> > [A worse alternative (no need to mention this): >>>> > If the integrity of CDO but not other headers >>>> > needed to be protected, ESP with authentication >>>> > enabled could be used, which causes >>>> > authentication data to be added at the end of the >>>> > payload (not shown). Then, before decapsulation, >>>> > the tunnel egress would have to record the value >>>> > of CDO-copy. Having decrypted the inner, it could >>>> > then check that CDO-copy matched the CDO in the >>>> > inner. However, that would require another >>>> > update to RFC2406, so using AH would be >>>> > preferable, given we don't want to make ConEx >>>> > depend on updating both ends of an ESP tunnel - one end is bad enough.] >>>> > >>>> > HTH >>>> > Sorry for taking so long - I wrote most of this >>>> > on a plane on Thu, but left some fact checking >>>> > for when I got online, and this is the first chance I've had to get >>>>back to it. >>>> > >>>> > Cheers >>>> > >>>> > >>>> > >>>> > Bob >>>> > >>>> >>>>>>>>> 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. " >>>> >>> OK. Rather than implying that equipment has evolved conscious >>>>awareness, >>>> >>> a better formulation would be something like: >>>> >>> "..the configuration of the tunnel ingress and the ConEx nodes is >>>> >>> co-ordinated." >>>> >>> >>>> >>> Nits: >>>> >>> s/SHOULD not/SHOULD NOT/ >>>> >>> s/accounted/counted/ >>>> >>> (in English, accounted is not a transitive verb, it has to have >>>>'for' >>>> >>> after it) >>>> >>> s/ingree/ingress/ >>>> >>> s/theses/these/ >>>> >> Done. >>>> >> >>>> >> >>>> >>> We're getting there! >>>> >> Yes...! >>>> >> >>>> >> Mirja >>>> >> >>>> >> >>>> >>> 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 >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>>>>>> ==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 >>>> >>>> ------------------------------------------ >>>> >>> ________________________________________________________________ >>>> >>> 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 >>>> > >>>> > >>> >>>________________________________________________________________ >>>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 Mon Sep 15 01:16:15 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 B90C81A011F for ; Mon, 15 Sep 2014 01:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 HGHcbTo98wJL for ; Mon, 15 Sep 2014 01:15:56 -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 03E101A0135 for ; Mon, 15 Sep 2014 01:15:48 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Sep 2014 09:15:41 +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; Mon, 15 Sep 2014 09:15:45 +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; Mon, 15 Sep 2014 09:15:39 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.110.124]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8F8FYlk021300; Mon, 15 Sep 2014 09:15:35 +0100 Message-ID: <201409150815.s8F8FYlk021300@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Sep 2014 09:15:32 +0100 To: Suresh Krishnan From: Bob Briscoe In-Reply-To: <54169A68.30000@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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> <540F0C78.7050309@tik.ee.ethz.ch> <201409091743.s89HheQJ021974@bagheera.jungle.bt.co.uk> <54169A68.30000@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/MXdNaqGMkINHy__SHYjZRqTsaX0 Cc: "ralli@tid.es" , "conex@ietf.org" Subject: Re: [conex] Act bits and Positioning (Was Re: 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, 15 Sep 2014 08:16:05 -0000 Suresh, You're best-placed to have experience of what the IESG will think of this. Personally, irrespective of the IESG, I wouldn't=20 REQUIRE any header to have to be processed first,=20 because it is so clearly impossible to state the=20 same requirement for other headers. Bob At 08:51 15/09/2014, Mirja K=FChlewind wrote: >I also would prefer to say that the CDO MUST be=20 >first and give it a try and see what the IESG=20 >says. If there are concerns, we can still change=20 >it to MUST be among the first 3... > >Mirja > > >On 12.09.2014 05:33, Suresh Krishnan wrote: >>Hi Bob/Mirja, >>Sounds fine to me as well. I can live with any value of X but the only >>one that really makes sense is 1 :-) >> >>Thanks >>Suresh >> >>-----Original Message----- >>*From:* Bob Briscoe [bob.briscoe@bt.com] >>*Received:* Tuesday, 09 Sep 2014, 1:44PM >>*To:* Mirja K=FChlewind [mirja.kuehlewind@tik.ee.ethz.ch] >>*CC:* Suresh Krishnan [suresh.krishnan@ericsson.com]; Carlos Ucendo >>[ralli@tid.es]; ConEx IETF list [conex@ietf.org] >>*Subject:* Re: Act bits and Positioning (Was Re: [conex] Fwd: Review: >>draft-ietf-conex-destopt-06) >> >>Mirja, >> >>Agree with you on all 3 new responses: >>* act bits =3D 00 >>* CDO SHOULD be first destopt, and MUST be among >>the first X destopts: that works for me. >> X=3D3? >>* CDO is always in the destopt position before >>any IPsec, and ConEx doesn't work within an ESP tunnel. >> >> >>Bob >> >>At 15:19 09/09/2014, Mirja K=FChlewind wrote: >>>Hi, >>> >>>see inline >>> >>>On 09.09.2014 09:59, Bob Briscoe wrote: >>>>Suresh, >>>> >>>>At 05:36 09/09/2014, Suresh Krishnan wrote: >>>>>Hi Bob, >>>>> Thanks a lot for your comments. I will respond to two specific= issues >>>>>that you brought up >>>>> >>>>>act bits being 01: Please note that the Conex option is a *destination* >>>>>option. Non conex-aware nodes on path will not even process the option. >>>>>So we do not need to be worried about the packet being dropped by >>>>>intermediate nodes, and we need to know if the destination does not >>>>>understand it. Hence I think this should stay as 01. >>>> >>>>I was aware that the act bits are only processed by the destination. >>>> >>>>My point was that ConEx only requires sender support (ie. you can have >>>>ConEx on one half-connection but not the other - there is no need to >>>>negotiate ConEx for a connection). So it would be very bad for a >>>>destination to drop a packet just before delivering it to the >>>>destination process just because it doesn't recognise a ConEx header >>>>that it doesn't need to understand anyway. >>>> >>>>Note to Mirja: Given this misunderstanding, perhaps the draft should >>>>give a reason: >>>> "The act bits MUST be 00, because a ConEx packet needs to be >>>>passed to the destination process even if the destination does not >>>>understand ConEx." >>>I agree with Bob, as the receiver does not need >>>to proceed the option in our case at all and it >>>does even know if it has to be there. Suresh? >>> >>>> >>>> >>>>>CDO as the first option: As you rightly note, this is just a= performance >>>>>optimization. I do believe that the performance penalty for conex-aware >>>>>nodes will be pretty severe if they need to process all destination >>>>>options before deciding if the CDO is present or not. >>>> >>>>Surely a ConEx node can stop when it gets to the CDO option (which will >>>>usually be first). It doesn't need to continue and process all the other >>>>options within the destopt header. >>>> >>>>>Please note that >>>>>this needs to be done on *all* packets passing through the conex aware >>>>>node. >>>> >>>>On packets without a destopt that is quick. >>>> >>>>The really bad case is for packets from senders that don't support ConEx >>>>but are using many other destopts. Then the on-path ConEx node would >>>>walk along every destopt until the end. >>>> >>>>>I do think it is OK to change the MUST to a SHOULD but with a >>>>>severe warning. >>>> >>>>OK, thanks. >>>> >>>>Would it be OK to say "As an optimization, a ConEx implementation MAY >>>>limit the depth of its search for CDO to two or three destination= options"? >>>My assumption was that search for the CDO if >>>multiple options are present is not feasible in fast path. >>> >>>So if the CDO is not first, there are two options: >>>1) forward the packet to slow path >>>2) ignore the CDO >>> >>>Actually case 1) is probably no option because >>>this would forward all present traffic to slow >>>path because none of the traffic has a CDO at all. >>> >>>2) is at least not feasible for something like a >>>policer that really needs to look at all ConEx-enable packets. >>> >>>Limiting the search depth, would translate into >>>"the CDO SHOULD be the first option and MUST be >>>among the first X options"... is that a solution? >>> >>> >>>Bob, see further below... >>> >>>> >>>> >>>>I have also added to my response to Mirja below, with an extra thought >>>>about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way >>>>down!)... >>>> >>>> >>>>>Cheers >>>>>Suresh >>>>> >>>>>On 09/08/2014 06:17 PM, Bob Briscoe wrote: >>>>> > Mirja, >>>>> > >>>>> > At 16:57 03/09/2014, Mirja K=FChlewind wrote: >>>>> >> Hi again, >>>>> >> >>>>> >> >>>>> >> On 28.08.2014 22:05, Bob Briscoe wrote: >>>>> >>>>>>>>>>>> * 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? >>>>> >>> The main problem is saying 'not available *for* control packets'.= But >>>>> >>> just changing 'for' to '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, given this is an >>>>> >>> example, so it can be specific. >>>>> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as >>>>>ACK are >>>>> >>> usually not 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 is (currently) >>>>>available >>>>> >>> e.g. in TCP if one endpoint has been receiving data but sending >>>>>nothing >>>>> >>> but pure ACKs (no user data) for some time. This is because pure >>>>>ACKs do >>>>> >>> not advance the sequence number, so the TCP endpoint receiving= them >>>>> >>> cannot reliably tell whether any have been lost due to congestion. >>>>>Pure >>>>> >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >>>>> >> Fine for me. Done. >>>>> >> >>>>> >> >>>>> >>>>>> 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... >>>>> >>> I thought the earlier definition said that ConEx accounts for the >>>>>size >>>>> >>> of the IP header that contains the CDO and everything within it. >>>>>Also, >>>>> >>> there's the TCP header size on a pure ACK. >>>>> >> Yes, especially when a network node accounts >>>>> >> ConEx marks. But in the (TCP) sender we just >>>>> >> don't care about the header bits for >>>>> >> simplification. We are aware that all bits will >>>>> >> be accounted but as we assume equal size packets that should be= fine. >>>>> >> >>>>> >> >>>>> >>> That's the basis on which I am assuming that pure ACKs are worth >>>>> >>> counting. A pure ACK will count as 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 be hard for TCP >>>>>to know >>>>> >>> though. >>>>> >> Yes, so how should I implement that? >>>>> > I guess just assume that any IP extensions will >>>>> > be constant on every packet in a flow, therefore >>>>> > assuming none will be similar to assuming some. >>>>> > >>>>> >>>> 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. >>>>> >>> Agreed (that this would affect tcp-mods, not destopt). >>>>> >>> >>>>> >>> What is 'this' that you aren't yet convinced by? >>>>> >> 'this' is the fact that I need to changed >>>>> >> something in the tcp mods document. I might >>>>> >> remove the statement (if existent) that control >>>>> >> packets should be not-ConEx capable but I would >>>>> >> still like to recommend it because I believe it >>>>> >> makes things overly complicated otherwise. The >>>>> >> point is I believe that at the location in the >>>>> >> (Linux) code where you implement the counting, >>>>> >> you don't even have the information how large >>>>> >> the pure ACK will be in the end... >>>>> > See next comment. >>>>> > >>>>> >>>>> 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...? >>>>> >>> I thought you were proposing that a TCP sender assumes all the >>>>>packets >>>>> >>> it sends are full-sized, even if they aren't. But I believe you= have >>>>> >>> said that is not what you proposed. >>>>> >> No, when reducing the congestion counter(s) we >>>>> >> use the actual number of payload bytes. We also >>>>> >> use the real number of acknowledged bytes to >>>>> >> increase the counter(s). We simply do not care >>>>> >> about the header bytes at all assuming that on >>>>> >> average all packets have the same size and >>>>> >> therefor the number of (marked) header bytes >>>>> >> (either ECN or ConEx) in total will be about right. >>>>> > OK. I understand now. >>>>> > >>>>> > Ultimately TCP has to put a number in the Data >>>>> > Offset field, so it has to know the size of its >>>>> > own header. However, for an initial >>>>> > (experimental) implementation, if you need your >>>>> > proposal to assume all TCP options within one >>>>> > flow are the same size, it would be reasonable >>>>> > (it's not actually true, e.g. SACK, but there >>>>> > should at least be no bias, so you will overstate as much as >>>>>understate). >>>>> > >>>>> > You say earlier that it is too complicated to >>>>> > implement code within TCP that knows the size of >>>>> > a pure ACK. If TCP code doesn't know the size of >>>>> > a TCP header, then Linux must be using magic >>>>> > instead of code. Because, surely, the whole point >>>>> > of the TCP code is to write a TCP header. >>>>> > >>>>> >>>>>>>>>>>> =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. traffic management= or >>>>> >>>> multipath routing where 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 we say 'MUST be >>>>>first'. >>>>> >>> And I think 'SHOULD be first' is a doable implementation for >>>>>ConEx-aware >>>>> >>> nodes. That is sufficient for experimental. Any experiments where >>>>> >>> general forwarding nodes access ConEx will already be reading a >>>>>destopt >>>>> >>> at every hop, which is not what was intended, but it would be= doable >>>>> >>> just for an experiment that wanted to prove ConEx has wider uses. >>>>> >> I know that this might be a problem with IESG review, but... it's >>>>>broken... >>>>> >> >>>>> >>> Everyone involved in IPv6 knows that the attempt to design >>>>>extensibility >>>>> >>> into v6 failed. It won't be news to the IESG that we can't add an >>>>> >>> extension that can be processed at every hop on the fast path. >>>>> >>> >>>>> >>> If a destopt is sufficient to prove ConEx useful, then >>>>>implementers will >>>>> >>> want to satisfy this demand. Then >>>>> >>> * either there is even more pressure on the IETF to address this >>>>>failing >>>>> >>> in v6 (and maybe someone will), >>>>> >>> * or ConEx has to continue with this destopt solution, just like >>>>> >>> everyone else is finding hacks round this failing in v6. >>>>> >>> >>>>> >>> But don't ask me. Ask Suresh. >>>>> >> Yes! Unfortunately he did not response until >>>>> >> now. Maybe he is/was on holidays; will ping him again. >>>>> >> >>>>> >> >>>>> >>>>>>> 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? >>>>> >>> * How to do ConEx when IPsec is also required (tunnel & transport >>>>>modes, >>>>> >>> and what to count). This may all be obvious now, but (IMO) it >>>>>would still >>>>> >>> be worth spelling out obvious things. >>>>> >>> * How to use IPsec to protect the integrity of CDO. >>>>> >> Okay, this is the text now: >>>>> >> >>>>> >> "Compatibility with use of IPsec >>>>> >> >>>>> >> In IPv6 there are two possible position of a >>>>> >> Destination Option header, either before the >>>>> >> Routing header or after the Encapsulating Security Payload (ESP) >>>>>header. >>>>> > BETTER?: >>>>> > In IPv6 a Destination Option header can be placed >>>>> > in two possible position in the order of possible >>>>> > headers, either before the Routing header or >>>>> > after the Encapsulating Security Payload (ESP) header. >>>>> > REASONING: >>>>> > We are talking about the positions where these >>>>> > headers /would/ be if they were there - they might not actually be >>>>>present. >>>>> > >>>>> >> If the packet is encrypted using IPSec tunnel >>>>> >> mode, the CDO MUST be placed in the destination >>>>> >> option before the Routing header such that it >>>>> >> does not get encrypted and can be read by immediate ConEx-aware= nodes. >>>>> > BETTER?: >>>>> > CDO MUST always be placed in a destination option >>>>> > header placed before where the routing header >>>>> > would be. Otherwise, if CDO were placed in the >>>>> > latter position and an ESP header were used, the CDO would be >>>>>encrypt the >>>>> > REASONING: >>>>> > (There is no need for it to ever be in the later >>>>> > position and it's best to always be in the same place.) >>>>> > >>>>> > >>>>> >> Note as the Authentication Header (AH) also only >>>>> >> protects fields after the AH header, the CDO is not authenticated >>>>>in this case. >>>>> > Need to say the encapsulator copies CDO from the >>>>> > inner IPv6 CDO before encrypting the inner. >>>>> > >>>>> > s/read by immediate/read by/ >>>>> > >>>>> > AH integrity protects the IPv6 header that encapsulates it. ESP does >>>>>not. >>>>> > >>>>> > >>>>> >> In IPSec transport mode both destination option >>>>> >> headers can be used, as the CDO is in both cases >>>>> >> visible to the network. If the transport network >>>>> >> can not be trusted, the Destination Option >>>>> >> header after the ESP header SHOULD be used to >>>>> >> ensure integrity of the ConEx information. If an >>>>> >> attacker would be able to remove the ConEx >>>>> >> marks, this could cause an audit device >>>>> >> to penalize the respective connection, while the >>>>> >> sender cannot easily detect that ConEx information is missing." >>>>> >> >>>>> >> Does this seem to be right now? >>>>> > Sorry, this is all wrong. One cannot use ESP to >>>>> > authenticate or protect the integrity of CDO by >>>>> > putting CDO after ESP, because ESP would then >>>>> > encrypt CDO so ConEx-aware nodes would not be >>>>> > able to read it. CDO always has to precede ESP, >>>>> > which is why I said CDO MUST always be in the first destopt= position. >>>>> > >>>>> > If the CDO header needs to be authenticated, AH >>>>> > can be used as in the second example below. AH >>>>> > protects the integrity of the whole IPv6 datagram >>>>> > it is encapsulated by (except non-predictable >>>>> > mutable fields). AH coverage includes the IPv6 >>>>> > header and extension headers before the AH >>>>> > header, and everything after the AH header too. >>>Sorry that's my fault; I thought, (similar to >>>ESP) the authentication header would only >>>authenticate headers after the AH. (Checked=20 >>>now with rfc4302 that I was wrong.) >>> >>>>> > >>>>> > I think it would be worth listing the two or >>>>> > three example header sequences in the draft, as >>>>> > below. Headers in [] need not be present. Headers in {} are= encrypted. >>>>> > >>>>> > Transport mode without the integrity of CDO protected: >>>>> > IPv6 >>>>> > [Hop-by-Hop] >>>>> > [Routing] >>>>> > Destopt(CDO[,...]) >>>>> > [Fragment] >>>>> > ESP{ >>>>> > [Destopt] >>>>> > Upper-Layer >>>>> > } >>>>> > >>>>> > Transport mode with the integrity of CDO protected: >>>>> > IPv6 >>>>> > [Hop-by-Hop] >>>>> > [Routing] >>>>> > Destopt(CDO[,...]) >>>>> > [Fragment] >>>>> > AH >>>>> > ESP{ >>>>> > [Destopt] >>>>> > Upper-Layer >>>>> > } >>>>> > >>>>> > >>>>> > Tunnel mode: >>>>> > IPv6 >>>>> > [Hop-by-Hop] >>>>> > [Routing] >>>>> > Destopt(CDO-copy[,...]) >>>>> > [Fragment] >>>>> > ESP{ >>>>> > IPv6 >>>>> > Destopt(CDO[,...]) >>>>> > Transport Payload >>>>> > } >>>>> > >>>>> > For ESP in tunnel mode, as already stated in the >>>>> > draft, the tunnel ingress MUST copy the CDO from >>>>> > the destopt in the inner, then write a copy of >>>>> > the CDO header into a destopt header in the outer. >>>>> > >>>>> > I think this updates RFC2406. However, it is >>>>> > possible that 2406 already requires an ESP >>>>> > ingress to copy any extension headers, up to and >>>>> > including Fragmentation, to the outer. Because >>>>> > all these headers are designed to be visible to >>>>> > nodes on the path. Suresh may know this. >>>> >>>>I checked overnight and copying extension headers is contrary to the >>>>IPSec architecture. >>>> >>>> "IPv6 -- Header >>>>Construction for Tunnel Mode" says: >>>> "Extension headers never copied" >>>> >>>>On reflection, I don't think we should update RFC2401 for ConEx. If I >>>>were on the IESG, I would not approve that. IPsec needs to have simple >>>>rules without exceptions. >>>> >>>>When we chose destopt as the mechanism for ConEx, we knew it wasn't >>>>going to interact well with tunnels. I think the best approach is to= say, >>>> "Currently, the IPv6 protocol architecture does not provide a >>>>mechanism for new extension headers to be copied to the outer. Therefore >>>>ConEx functions will have to search for the CDO option within inner >>>>headers, and ConEx will not work at all over the extent of an ESP= tunnel". >>> >>>So all in all, this simplifies thing to >>>basically "CDO MUST be placed in the destination >>>option header before the AH and/or EPS (if present)." >>> >>>(+ our text just above on not interacting with tunnel mode) >>> >>>Right? >>> >>>Mirja >>> >>>> >>>> >>>>Bob >>>> >>>> >>>>> > >>>>> > To protect the integrity of the outer IPv6 >>>>> > datagram, including protecting the copy of CDO, >>>>> > an AH header (not shown) could be added before ESP. >>>>> > >>>>> > [A worse alternative (no need to mention this): >>>>> > If the integrity of CDO but not other headers >>>>> > needed to be protected, ESP with authentication >>>>> > enabled could be used, which causes >>>>> > authentication data to be added at the end of the >>>>> > payload (not shown). Then, before decapsulation, >>>>> > the tunnel egress would have to record the value >>>>> > of CDO-copy. Having decrypted the inner, it could >>>>> > then check that CDO-copy matched the CDO in the >>>>> > inner. However, that would require another >>>>> > update to RFC2406, so using AH would be >>>>> > preferable, given we don't want to make ConEx >>>>> > depend on updating both ends of an ESP tunnel - one end is bad= enough.] >>>>> > >>>>> > HTH >>>>> > Sorry for taking so long - I wrote most of this >>>>> > on a plane on Thu, but left some fact checking >>>>> > for when I got online, and this is the first chance I've had to get >>>>>back to it. >>>>> > >>>>> > Cheers >>>>> > >>>>> > >>>>> > >>>>> > Bob >>>>> > >>>>> >>>>>>>>> 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. " >>>>> >>> OK. Rather than implying that equipment has evolved conscious >>>>>awareness, >>>>> >>> a better formulation would be something like: >>>>> >>> "..the configuration of the tunnel ingress and the ConEx nodes is >>>>> >>> co-ordinated." >>>>> >>> >>>>> >>> Nits: >>>>> >>> s/SHOULD not/SHOULD NOT/ >>>>> >>> s/accounted/counted/ >>>>> >>> (in English, accounted is not a transitive verb, it has to have >>>>>'for' >>>>> >>> after it) >>>>> >>> s/ingree/ingress/ >>>>> >>> s/theses/these/ >>>>> >> Done. >>>>> >> >>>>> >> >>>>> >>> We're getting there! >>>>> >> Yes...! >>>>> >> >>>>> >> Mirja >>>>> >> >>>>> >> >>>>> >>> 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 >>>>> >> -- >>>>> >> ------------------------------------------ >>>>> >> 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 >>>>> > >>>>> > >>>> >>>>________________________________________________________________ >>>>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 Mon Sep 15 06:43:34 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717901A034E for ; Mon, 15 Sep 2014 06:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 1whGUyO3sEgi for ; Mon, 15 Sep 2014 06:43:26 -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 5DDA01A034B for ; Mon, 15 Sep 2014 06:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9F07BD930E; Mon, 15 Sep 2014 15:43:24 +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 sYRuu7s5WFB1; Mon, 15 Sep 2014 15:43:24 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f71746d.pool.mediaWays.net [95.113.116.109]) (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 6141BD9309; Mon, 15 Sep 2014 15:43:23 +0200 (MEST) Message-ID: <5416ECFA.9020602@tik.ee.ethz.ch> Date: Mon, 15 Sep 2014 15:43:22 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Bob Briscoe , Suresh Krishnan 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> <201408282005.s7SK5ke4004064@bagheera.jungle.bt.co.uk> <54073A5B.20207@tik.ee.ethz.ch> <201409082217.s88MHFDj018480@bagheera.jungle.bt.co.uk> <201409090759.s897xriV019964@bagheera.jungle.bt.co.uk> <540F0C78.7050309@tik.ee.ethz.ch> <201409091743.s89HheQJ021974@bagheera.jungle.bt.co.uk> <54169A68.30000@tik.ee.ethz.ch> <201409150815.s8F8FYlk021300@bagheera.jungle.bt.co.uk> In-Reply-To: <201409150815.s8F8FYlk021300@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/91uQqwBJTZZd31PCyn7yF8SYw6c Cc: "ralli@tid.es" , "conex@ietf.org" Subject: Re: [conex] Act bits and Positioning (Was Re: 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, 15 Sep 2014 13:43:32 -0000 Hi Bob, but usually there should also be no destination option that will be proceeded by intermediate nodes. As we are mis-using this anyway and assuming that this is not the usually case, it is unlikely that other options will also require to be placed first. Mirja On 15.09.2014 10:15, Bob Briscoe wrote: > Suresh, > > You're best-placed to have experience of what the IESG will think of this. > > Personally, irrespective of the IESG, I wouldn't REQUIRE any header to > have to be processed first, because it is so clearly impossible to state > the same requirement for other headers. > > > Bob > > At 08:51 15/09/2014, Mirja Kühlewind wrote: >> I also would prefer to say that the CDO MUST be first and give it a >> try and see what the IESG says. If there are concerns, we can still >> change it to MUST be among the first 3... >> >> Mirja >> >> >> On 12.09.2014 05:33, Suresh Krishnan wrote: >>> Hi Bob/Mirja, >>> Sounds fine to me as well. I can live with any value of X but the only >>> one that really makes sense is 1 :-) >>> >>> Thanks >>> Suresh >>> >>> -----Original Message----- >>> *From:* Bob Briscoe [bob.briscoe@bt.com] >>> *Received:* Tuesday, 09 Sep 2014, 1:44PM >>> *To:* Mirja Kühlewind [mirja.kuehlewind@tik.ee.ethz.ch] >>> *CC:* Suresh Krishnan [suresh.krishnan@ericsson.com]; Carlos Ucendo >>> [ralli@tid.es]; ConEx IETF list [conex@ietf.org] >>> *Subject:* Re: Act bits and Positioning (Was Re: [conex] Fwd: Review: >>> draft-ietf-conex-destopt-06) >>> >>> Mirja, >>> >>> Agree with you on all 3 new responses: >>> * act bits = 00 >>> * CDO SHOULD be first destopt, and MUST be among >>> the first X destopts: that works for me. >>> X=3? >>> * CDO is always in the destopt position before >>> any IPsec, and ConEx doesn't work within an ESP tunnel. >>> >>> >>> Bob >>> >>> At 15:19 09/09/2014, Mirja Kühlewind wrote: >>>> Hi, >>>> >>>> see inline >>>> >>>> On 09.09.2014 09:59, Bob Briscoe wrote: >>>>> Suresh, >>>>> >>>>> At 05:36 09/09/2014, Suresh Krishnan wrote: >>>>>> Hi Bob, >>>>>> Thanks a lot for your comments. I will respond to two specific >>>>>> issues >>>>>> that you brought up >>>>>> >>>>>> act bits being 01: Please note that the Conex option is a >>>>>> *destination* >>>>>> option. Non conex-aware nodes on path will not even process the >>>>>> option. >>>>>> So we do not need to be worried about the packet being dropped by >>>>>> intermediate nodes, and we need to know if the destination does not >>>>>> understand it. Hence I think this should stay as 01. >>>>> >>>>> I was aware that the act bits are only processed by the destination. >>>>> >>>>> My point was that ConEx only requires sender support (ie. you can have >>>>> ConEx on one half-connection but not the other - there is no need to >>>>> negotiate ConEx for a connection). So it would be very bad for a >>>>> destination to drop a packet just before delivering it to the >>>>> destination process just because it doesn't recognise a ConEx header >>>>> that it doesn't need to understand anyway. >>>>> >>>>> Note to Mirja: Given this misunderstanding, perhaps the draft should >>>>> give a reason: >>>>> "The act bits MUST be 00, because a ConEx packet needs to be >>>>> passed to the destination process even if the destination does not >>>>> understand ConEx." >>>> I agree with Bob, as the receiver does not need >>>> to proceed the option in our case at all and it >>>> does even know if it has to be there. Suresh? >>>> >>>>> >>>>> >>>>>> CDO as the first option: As you rightly note, this is just a >>>>>> performance >>>>>> optimization. I do believe that the performance penalty for >>>>>> conex-aware >>>>>> nodes will be pretty severe if they need to process all destination >>>>>> options before deciding if the CDO is present or not. >>>>> >>>>> Surely a ConEx node can stop when it gets to the CDO option (which >>>>> will >>>>> usually be first). It doesn't need to continue and process all the >>>>> other >>>>> options within the destopt header. >>>>> >>>>>> Please note that >>>>>> this needs to be done on *all* packets passing through the conex >>>>>> aware >>>>>> node. >>>>> >>>>> On packets without a destopt that is quick. >>>>> >>>>> The really bad case is for packets from senders that don't support >>>>> ConEx >>>>> but are using many other destopts. Then the on-path ConEx node would >>>>> walk along every destopt until the end. >>>>> >>>>>> I do think it is OK to change the MUST to a SHOULD but with a >>>>>> severe warning. >>>>> >>>>> OK, thanks. >>>>> >>>>> Would it be OK to say "As an optimization, a ConEx implementation MAY >>>>> limit the depth of its search for CDO to two or three destination >>>>> options"? >>>> My assumption was that search for the CDO if >>>> multiple options are present is not feasible in fast path. >>>> >>>> So if the CDO is not first, there are two options: >>>> 1) forward the packet to slow path >>>> 2) ignore the CDO >>>> >>>> Actually case 1) is probably no option because >>>> this would forward all present traffic to slow >>>> path because none of the traffic has a CDO at all. >>>> >>>> 2) is at least not feasible for something like a >>>> policer that really needs to look at all ConEx-enable packets. >>>> >>>> Limiting the search depth, would translate into >>>> "the CDO SHOULD be the first option and MUST be >>>> among the first X options"... is that a solution? >>>> >>>> >>>> Bob, see further below... >>>> >>>>> >>>>> >>>>> I have also added to my response to Mirja below, with an extra thought >>>>> about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way >>>>> down!)... >>>>> >>>>> >>>>>> Cheers >>>>>> Suresh >>>>>> >>>>>> On 09/08/2014 06:17 PM, Bob Briscoe wrote: >>>>>> > Mirja, >>>>>> > >>>>>> > At 16:57 03/09/2014, Mirja Kühlewind wrote: >>>>>> >> Hi again, >>>>>> >> >>>>>> >> >>>>>> >> On 28.08.2014 22:05, Bob Briscoe wrote: >>>>>> >>>>>>>>>>>> * 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? >>>>>> >>> The main problem is saying 'not available *for* control >>>>>> packets'. But >>>>>> >>> just changing 'for' to '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, given this is an >>>>>> >>> example, so it can be specific. >>>>>> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as >>>>>> ACK are >>>>>> >>> usually not 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 is (currently) >>>>>> available >>>>>> >>> e.g. in TCP if one endpoint has been receiving data but sending >>>>>> nothing >>>>>> >>> but pure ACKs (no user data) for some time. This is because pure >>>>>> ACKs do >>>>>> >>> not advance the sequence number, so the TCP endpoint receiving >>>>>> them >>>>>> >>> cannot reliably tell whether any have been lost due to >>>>>> congestion. >>>>>> Pure >>>>>> >>> TCP ACKs cannot be ECN-marked either [RFC3168]." >>>>>> >> Fine for me. Done. >>>>>> >> >>>>>> >> >>>>>> >>>>>> 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... >>>>>> >>> I thought the earlier definition said that ConEx accounts for the >>>>>> size >>>>>> >>> of the IP header that contains the CDO and everything within it. >>>>>> Also, >>>>>> >>> there's the TCP header size on a pure ACK. >>>>>> >> Yes, especially when a network node accounts >>>>>> >> ConEx marks. But in the (TCP) sender we just >>>>>> >> don't care about the header bits for >>>>>> >> simplification. We are aware that all bits will >>>>>> >> be accounted but as we assume equal size packets that should be >>>>>> fine. >>>>>> >> >>>>>> >> >>>>>> >>> That's the basis on which I am assuming that pure ACKs are worth >>>>>> >>> counting. A pure ACK will count as 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 be hard for TCP >>>>>> to know >>>>>> >>> though. >>>>>> >> Yes, so how should I implement that? >>>>>> > I guess just assume that any IP extensions will >>>>>> > be constant on every packet in a flow, therefore >>>>>> > assuming none will be similar to assuming some. >>>>>> > >>>>>> >>>> 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. >>>>>> >>> Agreed (that this would affect tcp-mods, not destopt). >>>>>> >>> >>>>>> >>> What is 'this' that you aren't yet convinced by? >>>>>> >> 'this' is the fact that I need to changed >>>>>> >> something in the tcp mods document. I might >>>>>> >> remove the statement (if existent) that control >>>>>> >> packets should be not-ConEx capable but I would >>>>>> >> still like to recommend it because I believe it >>>>>> >> makes things overly complicated otherwise. The >>>>>> >> point is I believe that at the location in the >>>>>> >> (Linux) code where you implement the counting, >>>>>> >> you don't even have the information how large >>>>>> >> the pure ACK will be in the end... >>>>>> > See next comment. >>>>>> > >>>>>> >>>>> 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...? >>>>>> >>> I thought you were proposing that a TCP sender assumes all the >>>>>> packets >>>>>> >>> it sends are full-sized, even if they aren't. But I believe >>>>>> you have >>>>>> >>> said that is not what you proposed. >>>>>> >> No, when reducing the congestion counter(s) we >>>>>> >> use the actual number of payload bytes. We also >>>>>> >> use the real number of acknowledged bytes to >>>>>> >> increase the counter(s). We simply do not care >>>>>> >> about the header bytes at all assuming that on >>>>>> >> average all packets have the same size and >>>>>> >> therefor the number of (marked) header bytes >>>>>> >> (either ECN or ConEx) in total will be about right. >>>>>> > OK. I understand now. >>>>>> > >>>>>> > Ultimately TCP has to put a number in the Data >>>>>> > Offset field, so it has to know the size of its >>>>>> > own header. However, for an initial >>>>>> > (experimental) implementation, if you need your >>>>>> > proposal to assume all TCP options within one >>>>>> > flow are the same size, it would be reasonable >>>>>> > (it's not actually true, e.g. SACK, but there >>>>>> > should at least be no bias, so you will overstate as much as >>>>>> understate). >>>>>> > >>>>>> > You say earlier that it is too complicated to >>>>>> > implement code within TCP that knows the size of >>>>>> > a pure ACK. If TCP code doesn't know the size of >>>>>> > a TCP header, then Linux must be using magic >>>>>> > instead of code. Because, surely, the whole point >>>>>> > of the TCP code is to write a TCP header. >>>>>> > >>>>>> >>>>>>>>>>>> ==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? >>>>>> >>> I think this will get thrown back by the IESG if we say 'MUST be >>>>>> first'. >>>>>> >>> And I think 'SHOULD be first' is a doable implementation for >>>>>> ConEx-aware >>>>>> >>> nodes. That is sufficient for experimental. Any experiments where >>>>>> >>> general forwarding nodes access ConEx will already be reading a >>>>>> destopt >>>>>> >>> at every hop, which is not what was intended, but it would be >>>>>> doable >>>>>> >>> just for an experiment that wanted to prove ConEx has wider uses. >>>>>> >> I know that this might be a problem with IESG review, but... it's >>>>>> broken... >>>>>> >> >>>>>> >>> Everyone involved in IPv6 knows that the attempt to design >>>>>> extensibility >>>>>> >>> into v6 failed. It won't be news to the IESG that we can't add an >>>>>> >>> extension that can be processed at every hop on the fast path. >>>>>> >>> >>>>>> >>> If a destopt is sufficient to prove ConEx useful, then >>>>>> implementers will >>>>>> >>> want to satisfy this demand. Then >>>>>> >>> * either there is even more pressure on the IETF to address this >>>>>> failing >>>>>> >>> in v6 (and maybe someone will), >>>>>> >>> * or ConEx has to continue with this destopt solution, just like >>>>>> >>> everyone else is finding hacks round this failing in v6. >>>>>> >>> >>>>>> >>> But don't ask me. Ask Suresh. >>>>>> >> Yes! Unfortunately he did not response until >>>>>> >> now. Maybe he is/was on holidays; will ping him again. >>>>>> >> >>>>>> >> >>>>>> >>>>>>> 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? >>>>>> >>> * How to do ConEx when IPsec is also required (tunnel & transport >>>>>> modes, >>>>>> >>> and what to count). This may all be obvious now, but (IMO) it >>>>>> would still >>>>>> >>> be worth spelling out obvious things. >>>>>> >>> * How to use IPsec to protect the integrity of CDO. >>>>>> >> Okay, this is the text now: >>>>>> >> >>>>>> >> "Compatibility with use of IPsec >>>>>> >> >>>>>> >> In IPv6 there are two possible position of a >>>>>> >> Destination Option header, either before the >>>>>> >> Routing header or after the Encapsulating Security Payload (ESP) >>>>>> header. >>>>>> > BETTER?: >>>>>> > In IPv6 a Destination Option header can be placed >>>>>> > in two possible position in the order of possible >>>>>> > headers, either before the Routing header or >>>>>> > after the Encapsulating Security Payload (ESP) header. >>>>>> > REASONING: >>>>>> > We are talking about the positions where these >>>>>> > headers /would/ be if they were there - they might not actually be >>>>>> present. >>>>>> > >>>>>> >> If the packet is encrypted using IPSec tunnel >>>>>> >> mode, the CDO MUST be placed in the destination >>>>>> >> option before the Routing header such that it >>>>>> >> does not get encrypted and can be read by immediate ConEx-aware >>>>>> nodes. >>>>>> > BETTER?: >>>>>> > CDO MUST always be placed in a destination option >>>>>> > header placed before where the routing header >>>>>> > would be. Otherwise, if CDO were placed in the >>>>>> > latter position and an ESP header were used, the CDO would be >>>>>> encrypt the >>>>>> > REASONING: >>>>>> > (There is no need for it to ever be in the later >>>>>> > position and it's best to always be in the same place.) >>>>>> > >>>>>> > >>>>>> >> Note as the Authentication Header (AH) also only >>>>>> >> protects fields after the AH header, the CDO is not authenticated >>>>>> in this case. >>>>>> > Need to say the encapsulator copies CDO from the >>>>>> > inner IPv6 CDO before encrypting the inner. >>>>>> > >>>>>> > s/read by immediate/read by/ >>>>>> > >>>>>> > AH integrity protects the IPv6 header that encapsulates it. ESP >>>>>> does >>>>>> not. >>>>>> > >>>>>> > >>>>>> >> In IPSec transport mode both destination option >>>>>> >> headers can be used, as the CDO is in both cases >>>>>> >> visible to the network. If the transport network >>>>>> >> can not be trusted, the Destination Option >>>>>> >> header after the ESP header SHOULD be used to >>>>>> >> ensure integrity of the ConEx information. If an >>>>>> >> attacker would be able to remove the ConEx >>>>>> >> marks, this could cause an audit device >>>>>> >> to penalize the respective connection, while the >>>>>> >> sender cannot easily detect that ConEx information is missing." >>>>>> >> >>>>>> >> Does this seem to be right now? >>>>>> > Sorry, this is all wrong. One cannot use ESP to >>>>>> > authenticate or protect the integrity of CDO by >>>>>> > putting CDO after ESP, because ESP would then >>>>>> > encrypt CDO so ConEx-aware nodes would not be >>>>>> > able to read it. CDO always has to precede ESP, >>>>>> > which is why I said CDO MUST always be in the first destopt >>>>>> position. >>>>>> > >>>>>> > If the CDO header needs to be authenticated, AH >>>>>> > can be used as in the second example below. AH >>>>>> > protects the integrity of the whole IPv6 datagram >>>>>> > it is encapsulated by (except non-predictable >>>>>> > mutable fields). AH coverage includes the IPv6 >>>>>> > header and extension headers before the AH >>>>>> > header, and everything after the AH header too. >>>> Sorry that's my fault; I thought, (similar to >>>> ESP) the authentication header would only >>>> authenticate headers after the AH. (Checked now with rfc4302 that I >>>> was wrong.) >>>> >>>>>> > >>>>>> > I think it would be worth listing the two or >>>>>> > three example header sequences in the draft, as >>>>>> > below. Headers in [] need not be present. Headers in {} are >>>>>> encrypted. >>>>>> > >>>>>> > Transport mode without the integrity of CDO protected: >>>>>> > IPv6 >>>>>> > [Hop-by-Hop] >>>>>> > [Routing] >>>>>> > Destopt(CDO[,...]) >>>>>> > [Fragment] >>>>>> > ESP{ >>>>>> > [Destopt] >>>>>> > Upper-Layer >>>>>> > } >>>>>> > >>>>>> > Transport mode with the integrity of CDO protected: >>>>>> > IPv6 >>>>>> > [Hop-by-Hop] >>>>>> > [Routing] >>>>>> > Destopt(CDO[,...]) >>>>>> > [Fragment] >>>>>> > AH >>>>>> > ESP{ >>>>>> > [Destopt] >>>>>> > Upper-Layer >>>>>> > } >>>>>> > >>>>>> > >>>>>> > Tunnel mode: >>>>>> > IPv6 >>>>>> > [Hop-by-Hop] >>>>>> > [Routing] >>>>>> > Destopt(CDO-copy[,...]) >>>>>> > [Fragment] >>>>>> > ESP{ >>>>>> > IPv6 >>>>>> > Destopt(CDO[,...]) >>>>>> > Transport Payload >>>>>> > } >>>>>> > >>>>>> > For ESP in tunnel mode, as already stated in the >>>>>> > draft, the tunnel ingress MUST copy the CDO from >>>>>> > the destopt in the inner, then write a copy of >>>>>> > the CDO header into a destopt header in the outer. >>>>>> > >>>>>> > I think this updates RFC2406. However, it is >>>>>> > possible that 2406 already requires an ESP >>>>>> > ingress to copy any extension headers, up to and >>>>>> > including Fragmentation, to the outer. Because >>>>>> > all these headers are designed to be visible to >>>>>> > nodes on the path. Suresh may know this. >>>>> >>>>> I checked overnight and copying extension headers is contrary to the >>>>> IPSec architecture. >>>>> >>>>> "IPv6 -- Header >>>>> Construction for Tunnel Mode" says: >>>>> "Extension headers never copied" >>>>> >>>>> On reflection, I don't think we should update RFC2401 for ConEx. If I >>>>> were on the IESG, I would not approve that. IPsec needs to have simple >>>>> rules without exceptions. >>>>> >>>>> When we chose destopt as the mechanism for ConEx, we knew it wasn't >>>>> going to interact well with tunnels. I think the best approach is >>>>> to say, >>>>> "Currently, the IPv6 protocol architecture does not provide a >>>>> mechanism for new extension headers to be copied to the outer. >>>>> Therefore >>>>> ConEx functions will have to search for the CDO option within inner >>>>> headers, and ConEx will not work at all over the extent of an ESP >>>>> tunnel". >>>> >>>> So all in all, this simplifies thing to >>>> basically "CDO MUST be placed in the destination >>>> option header before the AH and/or EPS (if present)." >>>> >>>> (+ our text just above on not interacting with tunnel mode) >>>> >>>> Right? >>>> >>>> Mirja >>>> >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>>>> > >>>>>> > To protect the integrity of the outer IPv6 >>>>>> > datagram, including protecting the copy of CDO, >>>>>> > an AH header (not shown) could be added before ESP. >>>>>> > >>>>>> > [A worse alternative (no need to mention this): >>>>>> > If the integrity of CDO but not other headers >>>>>> > needed to be protected, ESP with authentication >>>>>> > enabled could be used, which causes >>>>>> > authentication data to be added at the end of the >>>>>> > payload (not shown). Then, before decapsulation, >>>>>> > the tunnel egress would have to record the value >>>>>> > of CDO-copy. Having decrypted the inner, it could >>>>>> > then check that CDO-copy matched the CDO in the >>>>>> > inner. However, that would require another >>>>>> > update to RFC2406, so using AH would be >>>>>> > preferable, given we don't want to make ConEx >>>>>> > depend on updating both ends of an ESP tunnel - one end is bad >>>>>> enough.] >>>>>> > >>>>>> > HTH >>>>>> > Sorry for taking so long - I wrote most of this >>>>>> > on a plane on Thu, but left some fact checking >>>>>> > for when I got online, and this is the first chance I've had to get >>>>>> back to it. >>>>>> > >>>>>> > Cheers >>>>>> > >>>>>> > >>>>>> > >>>>>> > Bob >>>>>> > >>>>>> >>>>>>>>> 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. " >>>>>> >>> OK. Rather than implying that equipment has evolved conscious >>>>>> awareness, >>>>>> >>> a better formulation would be something like: >>>>>> >>> "..the configuration of the tunnel ingress and the ConEx nodes is >>>>>> >>> co-ordinated." >>>>>> >>> >>>>>> >>> Nits: >>>>>> >>> s/SHOULD not/SHOULD NOT/ >>>>>> >>> s/accounted/counted/ >>>>>> >>> (in English, accounted is not a transitive verb, it has to >>>>>> have >>>>>> 'for' >>>>>> >>> after it) >>>>>> >>> s/ingree/ingress/ >>>>>> >>> s/theses/these/ >>>>>> >> Done. >>>>>> >> >>>>>> >> >>>>>> >>> We're getting there! >>>>>> >> Yes...! >>>>>> >> >>>>>> >> Mirja >>>>>> >> >>>>>> >> >>>>>> >>> 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 >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>>>>>> ==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 >>>>>> >>>> ------------------------------------------ >>>>>> >>> ________________________________________________________________ >>>>>> >>> 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 >>>>>> > >>>>>> > >>>>> >>>>> ________________________________________________________________ >>>>> 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 Wed Sep 17 05:43: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 D28C61A0233; Wed, 17 Sep 2014 05:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O8XUjM3xOvV; Wed, 17 Sep 2014 05:43:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3A31A01A5; Wed, 17 Sep 2014 05:43:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917124310.30503.45404.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 05:43:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/4wV66NR4oeD5jYSmr4s0w1ZkR2Q Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-mobile-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 12:43:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : Mobile Communication Congestion Exposure Scenario Authors : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-04.txt Pages : 25 Date : 2014-09-17 Abstract: This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-mobile-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-mobile-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 17 05:51:44 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 7A69E1A0310 for ; Wed, 17 Sep 2014 05:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 sgRNvBqtjbER for ; Wed, 17 Sep 2014 05:51:40 -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 DCB3C1A02F3 for ; Wed, 17 Sep 2014 05:51:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 548E510021D for ; Wed, 17 Sep 2014 14:51:38 +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 x9IACEbNOshG for ; Wed, 17 Sep 2014 14:51:38 +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 3A6FD100099 for ; Wed, 17 Sep 2014 14:51:36 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.88]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 17 Sep 2014 14:51:36 +0200 From: Dirk Kutscher To: "conex@ietf.org" Thread-Topic: [conex] I-D Action: draft-ietf-conex-mobile-04.txt Thread-Index: AQHP0nUOLij+M1jM+0e886dTtYHAKpwFRqDw Date: Wed, 17 Sep 2014 12:51:35 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524991C83C9A@DAPHNIS.office.hd> References: <20140917124310.30503.45404.idtracker@ietfa.amsl.com> In-Reply-To: <20140917124310.30503.45404.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.212] 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/9utGtY2IgYTBxaicxyBy1x4wwJU Subject: Re: [conex] I-D Action: draft-ietf-conex-mobile-04.txt 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, 17 Sep 2014 12:51:42 -0000 Dear all, We updated the conex-mobile draft to reflect the comments that we received. Many thanks again to Nandita for the feedback. We have done the following changes: o added conex lite to deployment scenarios o added reference to LTE study paper at SIGCOMM-2013" o restructured section 2 and 3 (moved 3GPP specifics out of section2 o updated references Best regards, Dirk > -----Original Message----- > From: conex [mailto:conex-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Mittwoch, 17. September 2014 14:43 > To: i-d-announce@ietf.org > Cc: conex@ietf.org > Subject: [conex] I-D Action: draft-ietf-conex-mobile-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Congestion Exposure Working Group of th= e > IETF. >=20 > Title : Mobile Communication Congestion Exposure Scenar= io > Authors : Dirk Kutscher > Faisal Ghias Mir > Rolf Winter > Suresh Krishnan > Ying Zhang > Carlos J. Bernardos > Filename : draft-ietf-conex-mobile-04.txt > Pages : 25 > Date : 2014-09-17 >=20 > Abstract: > This memo describes a mobile communications use case for congestion > exposure (ConEx) with a particular focus on those mobile > communication networks that are architecturally similar to the 3GPP > Evolved Packet System (EPS). The draft provides a brief overview of > the architecture of these networks (both access and core networks), > current QoS mechanisms and then discusses how congestion exposure > concepts could be applied. Based on this, this memo suggests a set > of requirements for ConEx mechanisms that particularly apply to these > mobile networks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-conex-mobile-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-mobile-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From nobody Wed Sep 17 07:56:24 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0718E1A01E8 for ; Wed, 17 Sep 2014 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.253 X-Spam-Level: X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, 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 oL0OFFCOzH8m for ; Wed, 17 Sep 2014 07:56:19 -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 757121A0141 for ; Wed, 17 Sep 2014 07:56:19 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Sep 2014 15:56:17 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Sep 2014 15:56:17 +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, 17 Sep 2014 15:56:16 +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 s8HEuFoF030173; Wed, 17 Sep 2014 15:56:15 +0100 Message-ID: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Sep 2014 15:56:13 +0100 To: marcelo bagnulo braun , Nandita Dukkipati , 'ConEx IETF list' From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/84ohVfZVCqTD6Mfnf8t41_Sztoc Subject: Re: [conex] interim meeting 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, 17 Sep 2014 14:56:22 -0000 Marcelo, Nandita, ConEx-ers, The ConEx interim is coming up on Monday. I've added the details for the call below: At 18:41 22/07/2014, marcelo bagnulo braun wrote: >Hi, > >We are proposing to have an interim meeting on the monday 22nd >september at 1800 hrs CEST. >Please book the dates in your calendars. WebEx Participants: You should be able to get WebEx to call you back. Failing that pls dial in using the details below: BT Global MeetMe Local numbers around the world: A selection: From UK: 020 3463 9713 From US E Coast: 1 718 354 1289 From US W coast: 1 408 961 6587 PIN: 74407767# Any problems, email me. Bob >Regards, marcelo > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT From nobody Thu Sep 18 00:09: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 116141A70E1 for ; Thu, 18 Sep 2014 00:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.552 X-Spam-Level: X-Spam-Status: No, score=-8.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 WU8jjFkuJoyc for ; Thu, 18 Sep 2014 00:09:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C3C1A70FD for ; Thu, 18 Sep 2014 00:09:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgALAMSEGlSHCzIm/2dsb2JhbABeA4JqI1NXBLRYBpQPIgqHTQGBChYBAXiEAwEBAQEDAQEBDyg0FwQCAQgNBAQBAQEKFAkHJwsUCQgCBAESCBqIHAEMnw+gbwEXhgmJDBEBHyEXBguDHYEdBZFOkzCNVoNebIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,545,1406606400"; d="scan'208";a="72636176" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Sep 2014 03:09:36 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 18 Sep 2014 03:09:35 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 18 Sep 2014 09:09:33 +0200 From: "Romascanu, Dan (Dan)" To: Bob Briscoe , marcelo bagnulo braun , Nandita Dukkipati , "'ConEx IETF list'" Thread-Topic: [conex] interim meeting Thread-Index: AQHP0oePTcnYAjrU6U2GVsH9pzu9uZwGePww Date: Thu, 18 Sep 2014 07:09:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8A196F@AZ-FFEXMB04.global.avaya.com> References: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> In-Reply-To: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] 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/INuqUwErFlyMsHqOJFKUbR9G3Tc Subject: Re: [conex] interim meeting 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, 18 Sep 2014 07:09:48 -0000 What is the expected duration of the interim meeting?=20 Thanks and Regards, Dan > -----Original Message----- > From: conex [mailto:conex-bounces@ietf.org] On Behalf Of Bob Briscoe > Sent: Wednesday, September 17, 2014 5:56 PM > To: marcelo bagnulo braun; Nandita Dukkipati; 'ConEx IETF list' > Subject: Re: [conex] interim meeting >=20 > Marcelo, Nandita, ConEx-ers, >=20 > The ConEx interim is coming up on Monday. > I've added the details for the call below: >=20 > At 18:41 22/07/2014, marcelo bagnulo braun wrote: > >Hi, > > > >We are proposing to have an interim meeting on the monday 22nd > >september at 1800 hrs CEST. > >Please book the dates in your calendars. >=20 > WebEx Participants: >=20 > You should be able to get WebEx to call you back. > Failing that pls dial in using the details below: >=20 > BT Global MeetMe > Local numbers around the world: > > A selection: > From UK: 020 3463 9713 > From US E Coast: 1 718 354 1289 > From US W coast: 1 408 961 6587 >=20 > PIN: 74407767# >=20 > Any problems, email me. >=20 >=20 > Bob >=20 >=20 >=20 >=20 > >Regards, marcelo > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > __________________________________________________________ > ______ > Bob Briscoe, BT >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From nobody Thu Sep 18 00:11: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 3D73D1A70FD for ; Thu, 18 Sep 2014 00:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.853 X-Spam-Level: X-Spam-Status: No, score=-105.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Bmwu77_nju9L for ; Thu, 18 Sep 2014 00:10:56 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495401A710D for ; Thu, 18 Sep 2014 00:10:56 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8EA5C977D18; Thu, 18 Sep 2014 09:10:53 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from dummyhost19.it.uc3m.es (dummyhost19.it.uc3m.es [163.117.139.233]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 81F35976A12; Thu, 18 Sep 2014 09:10:53 +0200 (CEST) Message-ID: <541A857D.9070405@it.uc3m.es> Date: Thu, 18 Sep 2014 09:10:53 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Bob Briscoe , Nandita Dukkipati , 'ConEx IETF list' References: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> <9904FB1B0159DA42B0B887B7FA8119CA5C8A196F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8A196F@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-20960.004 X-TM-AS-Result: No--22.230-7.0-31-1 X-imss-scan-details: No--22.230-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/7GlULGGdRb5ek7mC7KTmopUoiAA Subject: Re: [conex] interim meeting 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, 18 Sep 2014 07:10:59 -0000 One and a half hour (i expect it to be less, but just to be safe) El 18/09/14 09:09, Romascanu, Dan (Dan) escribió: > What is the expected duration of the interim meeting? > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: conex [mailto:conex-bounces@ietf.org] On Behalf Of Bob Briscoe >> Sent: Wednesday, September 17, 2014 5:56 PM >> To: marcelo bagnulo braun; Nandita Dukkipati; 'ConEx IETF list' >> Subject: Re: [conex] interim meeting >> >> Marcelo, Nandita, ConEx-ers, >> >> The ConEx interim is coming up on Monday. >> I've added the details for the call below: >> >> At 18:41 22/07/2014, marcelo bagnulo braun wrote: >>> Hi, >>> >>> We are proposing to have an interim meeting on the monday 22nd >>> september at 1800 hrs CEST. >>> Please book the dates in your calendars. >> WebEx Participants: >> >> You should be able to get WebEx to call you back. >> Failing that pls dial in using the details below: >> >> BT Global MeetMe >> Local numbers around the world: >> >> A selection: >> From UK: 020 3463 9713 >> From US E Coast: 1 718 354 1289 >> From US W coast: 1 408 961 6587 >> >> PIN: 74407767# >> >> Any problems, email me. >> >> >> Bob >> >> >> >> >>> Regards, marcelo >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> __________________________________________________________ >> ______ >> Bob Briscoe, BT >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex From nobody Sun Sep 21 21:49:13 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 B20171A1A1A for ; Sun, 21 Sep 2014 21:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmKs69jbUMvj for ; Sun, 21 Sep 2014 21:49:08 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12DD1A1A18 for ; Sun, 21 Sep 2014 21:49:07 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id x69so3297046oia.8 for ; Sun, 21 Sep 2014 21:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=uw/hsLHgWDDUhXEadfz/b+1hXLLDznXnxg9zy6KXfL8=; b=MIZt6AzUcLcxG3zyZAQpSe+7sSoBx4mQoI1kYEU3dG+2A60sZjLU5Z4e1FJ8t4VHU3 L+Qjj7mlhbhn77YIh4uQL6dZxFhgXhapl2BQ2T29o1pOXsatA+zHfiGQ3V1qab5X9vCg /4SQlNJce9EqXfO2h0gCUKRiVGMaSR+uTbxXAw25sxNW2EEiaJn3VpibGcBblfNS3XGH jLWoJGst9VGcrZVd+xZiSbBo6pMXNUCd3lNAntwJX8uqqR9CRu6EmVanTrBQkTITN4lq Qimsc0eSFAvKVg5zjYFOGeWlLWTdfcL7asY+w/K9EVDfkThMZes4TWtrhb/5pThJl6i6 t3dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=uw/hsLHgWDDUhXEadfz/b+1hXLLDznXnxg9zy6KXfL8=; b=XxeksIovPir7cyO0ru4RsEew4kPR8Rkxcm1X4bRZdgvLTlhBYYFp++3gMMbj+RlqWv xodf+bLJEckYR6JebEe8zbkUii7XCrcg/ct6F2qMtIvuApXZXtxvDDvFjCN/LExlmR42 AY0nUcR6rWpWKncLrGYH2z5R0yCCqL2E8lCffNKA62rMiKbHjW0A5ChDbzJSs0tOc4uU xa7F4lGeVkYRCGoc5oE3vDp/T1vGNCYY3uRURCmGW1wnMSDOYW72D4PsiUxOzKEk1Lbg KLzjtKcPx7FgN7bBIMaC+Rl/BBFmSIAOigrQmenIUGrWyCPjo2Y+1wz6KMlDEhMLXhWD /xRA== X-Gm-Message-State: ALoCoQlZ8Jd4vgkTWhUkKbMozs/zc4ovhc9TmRamzvF50Ei8V5dZaAmXekDB+pbvKBcoAVfh68+/ MIME-Version: 1.0 X-Received: by 10.182.119.230 with SMTP id kx6mr174301obb.72.1411361347199; Sun, 21 Sep 2014 21:49:07 -0700 (PDT) Received: by 10.182.38.42 with HTTP; Sun, 21 Sep 2014 21:49:07 -0700 (PDT) Date: Sun, 21 Sep 2014 21:49:07 -0700 Message-ID: From: Nandita Dukkipati To: Bob Briscoe , "conex@ietf.org" Content-Type: multipart/alternative; boundary=001a11c30b94c024130503a02bd0 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/qR0Jqh28gtcVX8wQKhELnUbwTzk Subject: [conex] Angenda for ConEx interim meeting 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, 22 Sep 2014 04:49:09 -0000 --001a11c30b94c024130503a02bd0 Content-Type: text/plain; charset=UTF-8 The main focus of the interim meeting will be on the next two deliverables: TCP modifications draft, and the Destination options draft. In that light, we'll devote 30mins. of discussion on each of these I-D's, and leave the remainder 30mins. for any spill over discussion. Nandita On Wed, Sep 17, 2014 at 7:42 AM, Bob Briscoe wrote: > Marcelo, Nandita, ConEx-ers, > > The ConEx interim is coming up on Monday. > I've added the details for the call below: > > At 18:41 22/07/2014, marcelo bagnulo braun wrote: > >> Hi, >> >> We are proposing to have an interim meeting on the monday 22nd september >> at 1800 hrs CEST. >> Please book the dates in your calendars. >> > > WebEx Participants: > > You should be able to get WebEx to call you back. > Failing that pls dial in using the details below: > > BT Global MeetMe > Local numbers around the world: com/globalaccess/?bid=670> > A selection: > From UK: 020 3463 9713 > From US E Coast: 1 718 354 1289 > From US W coast: 1 408 961 6587 > > PIN: 74407767# > > Any problems, email me. > > > Bob > > > > > Regards, marcelo >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> > > ________________________________________________________________ > Bob Briscoe, BT > --001a11c30b94c024130503a02bd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The main focus of the interim m= eeting will be on the next two deliverables: TCP modifications draft, and t= he Destination options draft.=C2=A0

In that light, we'll devote 30mins. of di= scussion on each of these I-D's, and leave the remainder 30mins. for an= y spill over discussion.

Nandita

On Wed, Sep 17, 2014 at 7:42 AM, Bob Briscoe <bob.brisco= e@bt.com> wrote:
Marcelo,= Nandita, ConEx-ers,

The ConEx interim is coming up on Monday.
I've added the details for the call below:

At 18:41 22/07/2014, marcelo bagnulo braun wrote:
Hi,

We are proposing to have an interim meeting on the monday 22nd september at= 1800 hrs CEST.
Please book the dates in your calendars.

 WebEx Participants: <https://www.webjoin.com/?passcode=3D74407767= >

You should be able to get WebEx to call you back.
Failing that pls dial in using the details below:

BT Global MeetMe
=C2=A0Local numbers around the world: <http://www.btconferencin= g.com/globalaccess/?bid=3D670>
=C2=A0A selection:
=C2=A0From UK: 020 3463 9713
=C2=A0From US E Coast: 1 718 354 1289
=C2=A0From US W coast: 1 408 961 6587

PIN: 74407767#

Any problems, email me.


Bob




Regards, marcelo

_______________________________________________
conex mailing list
conex@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/conex

 _____________________________________________________________= ___
Bob Briscoe,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT

--001a11c30b94c024130503a02bd0-- From nobody Mon Sep 22 09:14:56 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 F076A1A1AE6 for ; Mon, 22 Sep 2014 09:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.987 X-Spam-Level: X-Spam-Status: No, score=-104.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 eX6CKpB5ystm for ; Mon, 22 Sep 2014 09:14:51 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9438F1A1B5B for ; Mon, 22 Sep 2014 09:14:51 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4E31297B724; Mon, 22 Sep 2014 18:14:49 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (145.186.221.87.dynamic.jazztel.es [87.221.186.145]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 12322966045; Mon, 22 Sep 2014 18:14:49 +0200 (CEST) Message-ID: <54204AF9.5060306@it.uc3m.es> Date: Mon, 22 Sep 2014 18:14:49 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , Nandita Dukkipati , 'ConEx IETF list' References: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> In-Reply-To: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-20970.000 X-TM-AS-Result: No--19.185-7.0-31-1 X-imss-scan-details: No--19.185-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/439IqEqxKJcldtd44f8-IDWRKDk Subject: Re: [conex] interim meeting 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, 22 Sep 2014 16:14:55 -0000 just to be clear, we are having the meeting now and we are in the following bridge. Only audio is working (webex is not working) El 17/09/14 16:56, Bob Briscoe escribió: > Marcelo, Nandita, ConEx-ers, > > The ConEx interim is coming up on Monday. > I've added the details for the call below: > > At 18:41 22/07/2014, marcelo bagnulo braun wrote: >> Hi, >> >> We are proposing to have an interim meeting on the monday 22nd >> september at 1800 hrs CEST. >> Please book the dates in your calendars. > > WebEx Participants: > > You should be able to get WebEx to call you back. > Failing that pls dial in using the details below: > > BT Global MeetMe > Local numbers around the world: > > A selection: > From UK: 020 3463 9713 > From US E Coast: 1 718 354 1289 > From US W coast: 1 408 961 6587 > > PIN: 74407767# > > Any problems, email me. > > > Bob > > > > >> Regards, marcelo >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT > From nobody Mon Sep 22 09:17:23 2014 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355CE1A1B66 for ; Mon, 22 Sep 2014 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.987 X-Spam-Level: X-Spam-Status: No, score=-104.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 1c8UrBQHSQA8 for ; Mon, 22 Sep 2014 09:17:18 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCF61A1A93 for ; Mon, 22 Sep 2014 09:17:17 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F3659D290EF for ; Mon, 22 Sep 2014 18:17:15 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (145.186.221.87.dynamic.jazztel.es [87.221.186.145]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id CF08FD290E0 for ; Mon, 22 Sep 2014 18:17:15 +0200 (CEST) Message-ID: <54204B8C.5000402@it.uc3m.es> Date: Mon, 22 Sep 2014 18:17:16 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: conex@ietf.org References: <201409171456.s8HEuFoF030173@bagheera.jungle.bt.co.uk> <54204AF9.5060306@it.uc3m.es> In-Reply-To: <54204AF9.5060306@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-20970.000 Archived-At: http://mailarchive.ietf.org/arch/msg/conex/nXQ5TSTf_sNfovIk1VQKb9ziOww Subject: Re: [conex] interim meeting 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, 22 Sep 2014 16:17:22 -0000 webex is working now El 22/09/14 18:14, marcelo bagnulo braun escribió: > just to be clear, we are having the meeting now and we are in the > following bridge. Only audio is working (webex is not working) > > El 17/09/14 16:56, Bob Briscoe escribió: >> Marcelo, Nandita, ConEx-ers, >> >> The ConEx interim is coming up on Monday. >> I've added the details for the call below: >> >> At 18:41 22/07/2014, marcelo bagnulo braun wrote: >>> Hi, >>> >>> We are proposing to have an interim meeting on the monday 22nd >>> september at 1800 hrs CEST. >>> Please book the dates in your calendars. >> >> WebEx Participants: >> >> You should be able to get WebEx to call you back. >> Failing that pls dial in using the details below: >> >> BT Global MeetMe >> Local numbers around the world: >> >> A selection: >> From UK: 020 3463 9713 >> From US E Coast: 1 718 354 1289 >> From US W coast: 1 408 961 6587 >> >> PIN: 74407767# >> >> Any problems, email me. >> >> >> Bob >> >> >> >> >>> Regards, marcelo >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >> >> ________________________________________________________________ >> Bob Briscoe, BT >> > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From nobody Fri Sep 26 03:04: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 AD2CC1A1AC7 for ; Fri, 26 Sep 2014 03:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 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.786] 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 aCs7S24MRUCJ for ; Fri, 26 Sep 2014 03:04:21 -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 3FD0F1A1ABF for ; Fri, 26 Sep 2014 03:04:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 83B8CD9305; Fri, 26 Sep 2014 12:04:19 +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 v3HybJHLIhjG; Fri, 26 Sep 2014 12:04:19 +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 35F9CD9302; Fri, 26 Sep 2014 12:04:19 +0200 (MEST) Message-ID: <54253A22.2050904@tik.ee.ethz.ch> Date: Fri, 26 Sep 2014 12:04:18 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: ConEx IETF list , Nandita Dukkipati Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/conex/t9iuX5oal64Nd7ig4IRYoK5c9qA Subject: [conex] TCP mods: Intro X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 10:04:23 -0000 Hi Nandita, hi all, find below the current version of the intro. Sorry for the delay; this week was a little busy... I applied the following changes: - Paragraph on CDO move back to intro (from section 4) - Added paragraph explaining that no receiver side changes are needed - Now introducing loss first - Added some sentences and the last paragraph to further explain the structure of the doc Mirja ------------------------------------------------------------- 1. Introduction Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. ConEx concepts and use cases are further explained in [RFC6789]. The abstract ConEx mechanism is explained in [draft-ietf-conex-abstract-mech]. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). ConEx is defined as a destination option for IPv6 [draft-ietf-conex-destopt]. The use of four bits have been defined, namely the X (ConEx-capable), the L (loss experienced), the E (ECN experienced) and C (credit) bit. Therefore the ConEx signal is based on loss or Explicit Congestion Notification (ECN) marks [RFC3168] as a congestion indication. This congestion information is retrieved by the sender based on existing feedback mechanisms from the receiver to the sender in TCP. No changes are needed at the receiver to implement ConEx signaling. Therefore no additional negotiation is needed to implement and use ConEx at the sender. This document specifies actions needed by sender to provide meaningful ConEx information to the network in section Section 2. Further this document describes congestion accounting for both TCP with and without the Selective Acknowledgment (SACK) extension [RFC2018] in section Section 3.1. However, ConEx benefits from more accurate information about the number of packets dropped in the network. We therefore recommend using the SACK extension when using TCP with ConEx. The detailed mechanism to respectively set the L bit in response to loss-based congestion feedback signal is given in section Section 4.1. While loss-based congestion feedback should be minimized, ECN could actually provide more fine-grained feedback information. ConEx-based traffic measurement or management mechanisms would benefit from this. Unfortunately, the current ECN feedback mechanism does not reflect multiple congestion markings which occur within the same Round-Trip Time (RTT). A more accurate feedback extension to ECN is defined in a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is also useful for other mechanisms. The congestion accounting for both, with the classic ECN feedback as well as a more accurate ECN feedback are explained in detail in section Section 3.2 while the setting of the E bit in response to ECN-based congestion feedback is again detailed in section Section 4.1.