I am very confused about the state of this. My skimming of the thread seems to indicate at least one unresolved issue.
Russ On Jan 2, 2012, at 1:04 PM, Joel M. Halpern wrote: > The clarification on U is very helpful. I look forward to comments from > others on the routing based behavior / ECMP text removal / replacement > question. > > On 1/2/2012 12:58 PM, Michael Menth wrote: >> Hi Joel, hi Tom, >> >> Am 02.01.2012 18:18, schrieb Joel M. Halpern: >>> Michael, I am not sure what to make of your recommended text abut ECMP. >>> ECMP is used by almost all operators. It is generally considered a >>> necessary tool in the tool-kit. >>> More significantly, at least for the egress understanding of the >>> ingress, it is not even the single operator's ECMP, but other >>> operators selections of paths that produce the issue. So even in the >>> unlikely event that this operator does not use ECMP, it still is not >>> sufficient. >> >> Then I better leave the ECMP issue for others to answer. >> >> The definition of U can be better corrected as follows (improved >> rewording of my previous email): >> >> U represents the average ratio of PCN-supportable-rate to >> PCN-admissible-rate over all the links of the PCN-domain. >> -> >> U is a domain-wide constant which implicitly defines the >> PCN-supportable-rate by U*PCN-admissible-rate on all links of the PCN >> domain. >> >> Best wishes, >> >> Michael >> >> >>> >>> Yours, >>> Joel >>> >>> On 1/2/2012 11:54 AM, Michael Menth wrote: >>>> Hi Tom, hi Joel, >>>> >>>> I wish you a happy new year! >>>> >>>> Here are my comments to address Joel's concerns: >>>> >>>> ==================================================================== >>>> >>>> The issue with ECMP: I'd add a comment that CL and SM should not be in >>>> the presence of ECMP if routing information is used to determine >>>> ingress-egress-aggregates since this seems to be messy and error-prone. >>>> >>>> ==================================================================== >>>> >>>> The following text may clarify at the beginning of Section 3.3.2 the >>>> relation >>>> between admission control and flow termination to address one of Joel's >>>> comments (for both SM and CL): >>>> >>>> In the presence of light pre-congestion, i.e., in the presence of a >>>> small, >>>> positive ETM-rate (relative to the overall PCN traffic rate), new >>>> flows may >>>> already be blocked. However, in the presence of heavy pre-congestion, >>>> i.e., >>>> in the presence of a relatively large ETM-rate, termination of some >>>> admitted >>>> flows is required. Thus, flow blocking is logical prerequisite for flow >>>> termination. >>>> >>>> ==================================================================== >>>> >>>> The following sentence in 3.3.2 should be corrected (only SM-specific): >>>> >>>> U represents the average ratio of PCN-supportable-rate to >>>> PCN-admissible-rate >>>> over all the links of the PCN-domain. >>>> >>>> -> >>>> >>>> U represents the ratio of PCN-supportable-rate to PCN-admissible-rate >>>> for all >>>> the links of the PCN-domain. >>>> >>>> ==================================================================== >>>> >>>> I also recommend to change the following text as I think it may cause >>>> misinterpretations (applies both to SM and CL): >>>> >>>> If the difference calculated in the second step is positive, the >>>> Decision >>>> Point SHOULD select PCN-flows to terminate, until it determines that the >>>> PCN-traffic admission rate will no longer be greater than the estimated >>>> sustainable aggregate rate. If the Decision Point knows the bandwidth >>>> required by individual PCN-flows (e.g., from resource signalling used to >>>> establish the flows), it MAY choose to complete its selection of >>>> PCN-flows to >>>> terminate in a single round of decisions. >>>> >>>> Alternatively, the Decision Point MAY spread flow termination over >>>> multiple >>>> rounds to avoid over-termination. If this is done, it is RECOMMENDED >>>> that >>>> enough time elapse between successive rounds of termination to allow the >>>> effects of previous rounds to be reflected in the measurements upon >>>> which the >>>> termination decisions are based. (See [IEEE-Satoh] and sections 4.2 >>>> and 4.3 >>>> of [MeLe10].) >>>> >>>> -> >>>> >>>> If the difference calculated in the second step is positive (traffic >>>> rate to >>>> be terminated), the Decision Point SHOULD select PCN-flows to >>>> terminate. To >>>> that end, the Decision Point MAY use upper rate limits for individual >>>> PCN-flows (e.g., from resource signalling used to establish the >>>> flows) and >>>> select a set of flows whose sum of upper rate limits is up to the >>>> traffic >>>> rate to be terminated. Then, these flows are terminated. The use of >>>> upper >>>> limits on flow rates avoids over-termination. >>>> >>>> Termination may be continuously needed after consecutive measurement >>>> intervals for various >>>> reasons, e.g., if the used upper rate limits overestimate the actual >>>> flow rates. >>>> For such cases it is RECOMMENDED that enough time elapses between >>>> successive >>>> termination events to allow the effects of previous termination events >>>> to be >>>> reflected in the measurements upon which the termination decisions are >>>> based; >>>> otherwise, over-termination may occur. See [IEEE-Satoh] and Sections 4.2 >>>> and >>>> 4.3 of [MeLe10]. >>>> >>>> ==================================================================== >>>> >>>> [IEEE-Satoh] is not a good key for Daisuke's work as the prefix "IEEE" >>>> makes it look like a reference to a standards document. >>>> You better use [SaUe10] or [Satoh10]. Applies both to CL and SM. >>>> >>>> >>>> >>>> Best wishes, >>>> >>>> Michael >>>> >>>> >>>> Am 02.01.2012 15:21, schrieb Tom Taylor: >>>>> It shall be as you say, subject to comment from my co-authors when >>>>> they get back from holiday. >>>>> >>>>> On 01/01/2012 5:43 PM, Joel M. Halpern wrote: >>>>>> In-line... >>>>>> >>>>>> On 1/1/2012 4:06 PM, Tom Taylor wrote: >>>>>>> >>>>>>> >>>>>>> On 01/01/2012 2:58 PM, Joel M. Halpern wrote: >>>>>>>> Thank you for responding promptly Tom. Let me try to elaborate on >>>>>>>> the >>>>>>>> two issues where I was unclear. >>>>>>>> >>>>>>>> On the ingress-egress-aggregate issue and ECMP, the concern I >>>>>>>> have is >>>>>>>> relative to the third operational alternative where routing is >>>>>>>> used to >>>>>>>> determine where the ingress and egress of a flow is. To be blunt, >>>>>>>> as far >>>>>>>> as I can tell this does not work. >>>>>>>> 1) It does not work on the ingress side because traffic from a given >>>>>>>> source prefix can come in at multiple places. Some of these >>>>>>>> places may >>>>>>>> claim reachability to the source prefix. Some may not. While a given >>>>>>>> flow will use only one of these paths, there is no way to determine >>>>>>>> from >>>>>>>> routing information, at the egress, which ingress that flow used. >>>>>>>> 2) A site may use multiple exits for a given destination prefix. >>>>>>>> Again, >>>>>>>> while the site will only use one of these egresses for a given flow, >>>>>>>> there is no way for the ingress to know which egress it will be >>>>>>>> on the >>>>>>>> basis of routing information. >>>>>>>> Thus, the text seems to allow for a behavior that simply does not >>>>>>>> work. >>>>>>> >>>>>>> [PTT] I think the disconnect here is that you read the text to say >>>>>>> that >>>>>>> an individual node uses routing information to determine the IEA. >>>>>>> That >>>>>>> wasn't the intention. Instead, administrators use routing >>>>>>> information to >>>>>>> derive filters that are installed at the ingress and egress nodes. >>>>>> >>>>>> As far as I can tell, your response describes a situation even less >>>>>> effective than what I assumed. >>>>>> Firstly, it does not matter whether it is the edge node, the decision >>>>>> node, or the human administrator. Routing information is not enough to >>>>>> determine what the ingress-egress pairing is. The problems I describe >>>>>> above apply no matter who is making the decision. >>>>>> Secondly, having a human make the decision means that as soon as >>>>>> routing >>>>>> changes, the configured filters are wrong. >>>>>> >>>>>> I would suggest that the text in question be removed, and replaced >>>>>> with >>>>>> a warning against attempting what is currently described. >>>>>> >>>> My view is also that CL ans SM do not work in the presence of ECMP. This >>>> should be indicated as a warning. >>>> >>>>>>>> >>>>>>>> I am still confused about the relationship of section 3.3.2 to the >>>>>>>> behavior you describe. 3.3.2 says that as long as any excess >>>>>>>> traffic is >>>>>>>> being reported, teh decision point shall direct the blocking of >>>>>>>> additional flows. That does not match 3.3.1, and does not match your >>>>>>>> description. >>>>>>> >>>>>>> [PTT] I can't see the text in section 3.3.2 that says you continue to >>>>>>> block as long as any excess traffic is being reported. What I >>>>>>> think it >>>>>>> says is that as long as excess traffic is reported, the decision >>>>>>> point >>>>>>> checks to see whether the traffic being admitted to the aggregate >>>>>>> exceeds the supportable level. Excess traffic may be non-zero, yet no >>>>>>> termination may be required (i.e., traffic is below the second >>>>>>> threshold). >>>>>> >>>>>> I think I see what you are saying. If I am reading this correctly, the >>>>>> decision process must re-calculate to determine if there is >>>>>> termination >>>>>> every time it receives a report with non-zero excess and the port is >>>>>> already blocked. But it does not have to actually block anything. >>>>>> This however seems to depend upon the correct relative >>>>>> configuration of >>>>>> the limit that flips it into blocked state, the value of U, and maybe >>>>>> some other values. >>>>>> Put differently, I understand that the two are not contradictory. >>>>>> However, since the two things use different calculations, it is not at >>>>>> all clear that they are consistent. This may well be acceptable. >>>>>> But the >>>>>> difference in methods is likely to lead to confusion. So, as a minor >>>>>> (rather than major) comment, I would suggest that you provide >>>>>> clarifying >>>>>> text explaining why it is okay to use one condition to decide if there >>>>>> is blocking, but a different condition (which could produce a lower >>>>>> threshold) to decide how much to get rid of. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 1/1/2012 2:48 PM, Tom Taylor wrote: >>>>>>>>> Thanks for the review, Joel. Comments below, marked with [PTT]. >>>>>>>>> >>>>>>>>> On 31/12/2011 4:50 PM, Joel M. Halpern wrote: >>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. For >>>>>>>>>> background on >>>>>>>>>> Gen-ART, please see the FAQ at >>>>>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>>>>>>> >>>>>>>>>> Please resolve these comments along with any other Last Call >>>>>>>>>> comments >>>>>>>>>> you may receive. >>>>>>>>>> >>>>>>>>>> Document: draft-ietf-pcn-sm-edge-behaviour-08 >>>>>>>>>> PCN Boundary Node Behaviour for the Single Marking (SM) Mode of >>>>>>>>>> Operation >>>>>>>>>> Reviewer: Joel M. Halpern >>>>>>>>>> Review Date: 31-Dec-2011 >>>>>>>>>> IETF LC End Date: 13-Jan-2012 >>>>>>>>>> IESG Telechat date: N/A >>>>>>>>>> >>>>>>>>>> Summary: This documents is almost ready for publication as an >>>>>>>>>> Informational RFC. >>>>>>>>>> >>>>>>>>>> Question: Given that the document defines a complex set of >>>>>>>>>> behaviors, >>>>>>>>>> which are mandatory for compliant systems, it seems that this >>>>>>>>>> ought to >>>>>>>>>> be Experimental rather than Informational. It describes something >>>>>>>>>> that >>>>>>>>>> could, in theory, later become standards track. >>>>>>>>> >>>>>>>>> [PTT] OK, we've wobbled on this one, but we can follow your >>>>>>>>> suggestion. >>>>>>>>>> >>>>>>>>>> Major issues: >>>>>>>>>> Section 2 on Assumed Core Network Behavior for SM, in the third >>>>>>>>>> bullet, >>>>>>>>>> states that the PCN-domain satisfies the conditions specified >>>>>>>>>> in RFC >>>>>>>>>> 5696. Unfortunately, look at RFC 5696 I can not tell what >>>>>>>>>> conditions >>>>>>>>>> these are. Is this supposed to be a reference to RFC 5559 >>>>>>>>>> instead? No >>>>>>>>>> matter which document it is referencing, please be more specific >>>>>>>>>> about >>>>>>>>>> which section / conditions are meant. >>>>>>>>> >>>>>>>>> [PTT] You are right that RFC 5696 isn't relevant. It's such a long >>>>>>>>> time >>>>>>>>> since that text was written that I can't recall what the intention >>>>>>>>> was. >>>>>>>>> My inclination at the moment is simply to delete the bullet. >>>>>>>>>> >>>>>>>>>> It would have been helpful if the early part of the document >>>>>>>>>> indicated >>>>>>>>>> that the edge node information about how to determine >>>>>>>>>> ingress-egress-aggregates was described in section 5. >>>>>>>>>> In conjunction with that, section 5.1.2, third paragraph, seems to >>>>>>>>>> describe an option which does not seem to quite work. After >>>>>>>>>> describing >>>>>>>>>> how to use tunneling, and how to work with signaling, the text >>>>>>>>>> refers to >>>>>>>>>> inferring the ingress-egress-aggregate from the routing >>>>>>>>>> information. In >>>>>>>>>> the presence of multiple equal-cost domain exits (which does >>>>>>>>>> occur in >>>>>>>>>> reality), the routing table is not sufficient information to make >>>>>>>>>> this >>>>>>>>>> determination. Unless I am very confused (which does happen) this >>>>>>>>>> seems >>>>>>>>>> to be a serious hole in the specification. >>>>>>>>> >>>>>>>>> [PTT] I'm not sure what the issue is here. As I understand it, >>>>>>>>> operators >>>>>>>>> don't assign packets randomly to a given path in the presence of >>>>>>>>> alternatives -- they choose one based on values in the packet >>>>>>>>> header. >>>>>>>>> The basic intent is that packets of a given microflow all follow >>>>>>>>> the >>>>>>>>> same path, to prevent unnecessary reordering and minimize >>>>>>>>> jitter. The >>>>>>>>> implication is that filters can be defined at the ingress nodes to >>>>>>>>> identify the packets in a given ingress-egress-aggregate (i.e. >>>>>>>>> flowing >>>>>>>>> from a specific ingress node to a specific egress node) based on >>>>>>>>> their >>>>>>>>> header contents. The filters to do the same job at egress nodes >>>>>>>>> are a >>>>>>>>> different problem, but they are not affected by ECMP. >>>>>>>>>> >>>>>>>>>> Minor issues: >>>>>>>>>> Section 3.3.1 states that the "block" decision occurs when the CLE >>>>>>>>>> (excess over total) rate exceeds the configured limit. However, >>>>>>>>>> section >>>>>>>>>> 3.3.2 states that the decision node must take further stapes if >>>>>>>>>> the >>>>>>>>>> excess rate is non-zero in further reports. Is this inconsistency >>>>>>>>>> deliberate? If so, please explain. If not, please fix. (If it is >>>>>>>>>> important to drive the excess rate to 0, then why is action only >>>>>>>>>> initiated when the ratio is above a configured value, rather than >>>>>>>>>> any >>>>>>>>>> non-zero value? I can conceive of various reasons. But none are >>>>>>>>>> stated.) >>>>>>>>> >>>>>>>>> [PTT] We aren't driving the excess rate to zero, but to a value >>>>>>>>> equal to >>>>>>>>> something less than (U - 1)/U. (The "something less" is because of >>>>>>>>> packet dropping at interior nodes.) The assumption is that (U - >>>>>>>>> 1)/U is >>>>>>>>> greater than CLE-limit. Conceptually, PCN uses two thresholds. >>>>>>>>> When the >>>>>>>>> CLE is below the first threshold, new flows are admitted. Above >>>>>>>>> that >>>>>>>>> threshold, they are blocked. When the CLE is above the second >>>>>>>>> threshold, >>>>>>>>> flows are terminated to bring them down to that threshold. In >>>>>>>>> the SM >>>>>>>>> mode of operation, the first threshold is specified directly on a >>>>>>>>> per-link basis by the value CLE-limit. The second threshold is >>>>>>>>> specified >>>>>>>>> by the same value (U - 1)/U for all links. With the CL mode of >>>>>>>>> operation >>>>>>>>> the second threshold is also specified directly for each link. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Nits/editorial comments: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
