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

["Joel M. Halpern" <[e-mail]>]

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.

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.

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