Re: [Gen-art] Review: draft-ietf-pcn-sm-edge-behaviour-08

[Tom Taylor <[e-mail]>]

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.
>
>>>
>>> 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:
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>