Re: [PCN] SM Edge Behaviour Draft

[Tom Taylor <tom.taylor at rogers.com>]

It's time I responded to your comments. It will be a warm-up for revising the 
draft. Thank you very much for your review. Responses marked with [PTT].

Ruediger.Geib at telekom.de wrote:
> Tom,
>
> thanks for your work. The draft is clearer than the first version. I 
> still miss details how to measure an IEA. That the "howto" is an 
> issue isn't even mentioned in the draft.

[PTT] We discussed this in Stockholm. The answer to how to classify packets 
really depends on the specific deployment. It could be a matter of tunnels, 
LSPs, or 5-tuples matched against routing information. Our conclusion was that 
the issue really should have been discussed in the architecture document, but 
the next-best alternative may be the signalling requirements document. 
Re-thinking that conclusion after a couple of months, I guess we really are 
talking about edge behaviour, so it is a proper topic for the edge behaviour 
documents.
> Regards,
>
> Ruediger
>
>
> Some comments:
>
> 1.1 terminology and following cahpters
>
> A new PCN node called "Policy Decision Point" is added to the architecture. 
> The document does not explain where it is located and by which interfaces 
> and priotocols it communicates. The draft text however seems to make this
> PDP mandatory in some instances.
>
> My personal take: remove the "Policy Decision Point" and all references to
> it from this draft and write an experimental architecture draft explaining
> the concept.
[PTT] The terminology was used because I thought it would be familiar. Perhaps I 
should revert to the "decision node" terminology used in the earlier version of 
this document. I do see your point about a separate architecture draft, but we 
already have some support for the concept of a central control node in RFC 5559. 
I was hoping we could keep it in view in the edge behaviour drafts.

> -----------------
>
> 3.1 Overview
>
> 2nd section: ..."measured rate of flow of unmarked..." 
> replace by  "..measured rate of unmarked.." 
[PTT] OK.
> -----------------
>
> 3.2.1 PCN Egress Node Role in flow admission
>
> new_CLE is the value of old_CLE during the next iteration, but the text 
> doesn't state that. As you never know what an implementor understands 
> from this text, the formula may be changed or text added.
[PTT] OK.

> "k" should be from  0 < k < 1. The text should state that.
[PTT] OK.

> Typo: Replace old-CLE/new-CLE by old_CLE/new_CLE
[PTT] OK.

> ------------------
>
> 3.4 Possible Extensions to the basic algorithm
>
> End of first section: "....is low (< 50 flows). "
>
> If this holds independent of the flow size, leave as is. If it makes a 
> difference whether these are voice calls or HD video streams, please 
> explain "50 flows" in sufficient detail.
[PTT] I'll consult with my co-authors.
> -------------------
>
> 4.7 Environmental Concerns
>
> Please change the 2nd sentence
>
> If the mechanism flow termination can't be enabled, signaling the 
> corresponding state may be used to reduce traffic by other means 
> like codec adaptation or the drop of low priority video frames.
> This is however out of scope of the PCN WG.
[PTT] I'll review. I have the feeling someone else commented on this, and when I 
get to that comment I'll have a better idea what to do.

> -------------------
>
> 4.8 and 5. Security Considerations
>
> Delete one section.

[PTT] OK.
>