Subject: [PCN] Comments on the architecture draft

From: "Anna Charny (acharny)" <[email-masked]>
Date: Tue, 6 Nov 2007 22:34:21 -0500

Hi Phil,

The draft is looking really good.
Here are a few comments/questions though:

Page 5:

>Depending on the deployment scenario, the decision-making
> functionality (about flow admission and termination) could reside
> at the PCN-ingress-nodes or PCN-egress-nodes or at some central
> control node in the PCN-domain.  NOTE: The Charter restricts us:
> the decision-making functionality is at the PCN-boundary-nodes

Does it mean that we should first define the specific deployment
scenarios of interest and then define the boundary-node functionality,
or the other way around? 

Page 6:

>The PCN-domain extends to the end users.  NOTE: This is outside
>the Charter because it breaks Assumption 3 (aggregation, see
>later; ....

This does not necessarily break the aggregation assumption because the
aggregation assumption is at the *bottleneck*. Current charter does not
preclude this at the moment (although ongoing discussion on the list
questions whether explicit assumptions on ingress-egress aggregation
should be made)

Page 9:

(trust discussion)
>Similarly, a PCN-boundary-node has to trust that all the PCN-nodes
>are doing PCN-marking. 

Do we really need to require that *all* nodes do marking?  If some node
does not mark, then only its adjacent links are not handled.  Is the
above requirement too strict? (We do need to say there are no rogue
ones)

Page 12:

>the PCN-egress-node measures (possibly as a moving average) the
>fraction of the PCN-traffic that is PCN-marked.

Note that current 3sm proposal (at least as simulated) does not compute
CLE but acts on receipt of one or several marked packets to make an
admission-stop decision.

Page 18:

>A probe packet is just a dummy data packet, generated by
>the PCN-ingress-node and addressed to the PCN-egress-node

This seems to exclude using RSVP messages as probes

Page 23:

>ECMP and signaling: It is possible that, in a PCN-domain running
>ECMP, the signaling packets (eg RSVP, NSIS) follow a different
>path than the data packets.  This depends on which fields the ECMP
>algorithm uses.

The above seems of no consequence unless signaling messages are used as
probes - right?

Hope this is helpful,
Anna 

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 7 Nov 2007 11:32:45 -0000

Thanks anna,
In-line
phil

> -----Original Message-----
> From: Anna Charny (acharny) [mailto:[email-masked]]
> Sent: 07 November 2007 03:34
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Subject: Comments on the architecture draft
> 
> Hi Phil,
> 

[phil] I think personally I tend to think about it more along your
"first" lines, though I don't think it matters if others think on the
"second" lines. (is this a cop out?!)  The para was just supposed to say
that we'll only define decision-making at boundary nodes and only
consider such scenarios. 

> questions whether explicit assumptions on ingress-egress aggregation

ok, will re-phrase

> above requirement too strict? (We do need to say there are no rogue

ok, I could add a caveat that if it's known that an interface cannot
become pre-congested then PCN-marking on it will never be done & so the
functionality isn't strictly necessary. Eg it's possibly to design by
topology to ensure this - however, note the danger: if the topology
changes (upgrade network; some links have failed elsewhere in
PCN-domain) then it can no longer be guaranteed.  

> CLE but acts on receipt of one or several marked packets to make an

Arrgh. I'll try and re-word. 

> This seems to exclude using RSVP messages as probes

will add.

> The above seems of no consequence unless signaling messages are used
as

think this is true.
> Hope this is helpful,

yes, thanks!