Subject: Re: [PCN] some comments on pcn-architecture-02

From: <[email-masked]>
Date: Wed, 6 Feb 2008 15:18:00 -0000

Rob
I've finally got to dealing with these comments. Thanks for the careful
scrutiny. Most excitingly, these all involved changes to the draft.
In-line.
phil

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: 30 November 2007 10:53
> To: Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
> Subject: some comments on pcn-architecture-02
> 
> Hi all,
> 
> Some comments on the architecture draft, mainly (but not totally)
> stimulated by the ECN discussion.
> 
> 1. The draft is mainly about what building blocks are needed to
> construct a PCN domain. That's fair enough; however, it would also be
> nice to have some overview of how a PCN domain looks (as a "black
> network") to the outside world. If I'm primarily interested in
terminals
> or edge networks then I don't really care about how ingress and egress
> nodes communicate, or OAM, or internal encoding issues, but I do care
> about how the introduction of PCN will affect my traffic. This
> discussion would be short if the PCN domain was transparent in which
> case that's all that needs to be said. However, if for example the
> domain blocks packets with particular bit patterns in particular
> circumstances, I'd like to know what those circumstances are, and what
-
> if anything - I can do about them (and to have that information
> conveniently centralised).

Added new para at end of S1 Intro:
From the perspective of the outside world, a PCN-domain essentially
looks like a DiffServ. PCN-traffic is either transported across it
transparently or policed at the PCN-ingress-node (ie dropped or carried
at a lower QoS). A couple of differences are that: PCN-traffic has
better QoS guarantees than normal DiffServ traffic (because PCN's
mechanisms better protects the QoS of admitted flows); and in rare
circumstances (failures) on the one hand some PCN-flows may get
terminated, but on the other hand other flows will get their QoS
restored. Non PCN-traffic is treated transparently, ie the PCN-domain is
a normal DiffServ domain. 

> 
> 2. The draft uses the term 'PCN-flow' several times without defining
it.
> I imagine that a PCN-flow could be defined as just a subset of
> PCN-traffic, but I'm not clear how arbitrary those subsets could be.
> (Does a subset have to have a single ingress/egress? Can subsets
> nest/overlap? Do all the ingress/egress nodes have to agree on what
the
> subsets are?) It may be that a PCN-flow is just one of
> - whatever a boundary node decides to admit
> - whatever a boundary node decides to terminate
> and that the granularity of those decisions can be absolutely whatever
> one wants (but again it would be nice to say so).

Yes, your last sentence is the case, I believe. 

I've adjusted the definition of PCN-traffic in S2: 
PCN-traffic: A PCN-domain carries traffic of different DiffServ
behaviour aggregates. Those using the PCN mechanisms are called PCN-BAs
(collectively called PCN-traffic) and the corresponding packets are
PCN-packets. The same network may carry traffic using other DiffServ
BAs. A PCN-flow is the unit of PCN-traffic that the PCN-boundary-node
admits (or terminates); the unit could be a single microflow (as defined
in rfc2475) or some identifiable collection of microflows

[the super-observant will notice that I also adjusted 'PCN-classes' to
'PCN-BAs' - steven blake suggested this, for better matching diffserv
jargon]
> 
> 3. It's clear that the ingress nodes are responsible for deciding
> whether or not an incoming packet is a PCN packet, and that the
criteria
> for the decision are a header classifier. However, it's rather unclear
> what needs to be assumed about how these classifiers get installed. It
> may be that for most of the details of PCN operation, how the
> classifiers get installed just doesn't matter, but from the point of
> view of the external user or peer network it could be critical. (How
> does it work if a domain is working without admission control, as in
> section 4.3? Will an operator provision the classifiers statically?
Or,
> if there is rerouting which causes the ingress for a flow to change,
> whose job is it to move the classifiers around? And so on.)

I adjusted the last para pf S5.2 (PCN-ingress-node functions):
The first two are policing functions, needed to make sure that
PCN-packets admitted into the PCN-domain belong to a flow that's been
admitted and to ensure that the flow keeps to the flowspec agreed (eg
doesn't go at a faster rate and is inelastic traffic). Installing the
filter spec will typically be done by the signalling protocol, as will
re-installing the filter, for example after a re-route that changes the
PCN-ingress-node (see <xref
target="I-D.briscoe-tsvwg-cl-architecture"> for an example using RSVP).
PCN-colouring allows the rest of the PCN-domain to recognise
PCN-packets.

> 
> 4. There are a few comments in the draft (and elsewhere) about PCN
being
> intended for inelastic traffic. I think it needs to be really clear
what
> the significance of this assumption is. If the claim is "we know PCN
> will only be used for inelastic traffic therefore we can make a
> simplifying assumption about how to implement it" I think that's very
> dangerous. If the claim is "we only have to provide a benefit for
> inelastic traffic and nothing else sees any difference" that's quite
> safe. (To some extent this is tied up with point 3: if you stated
> explicitly how the PCN domain decided whether traffic was PCN traffic,
> then it would be clear to what extent the (in-)elasticity of the
> admitted traffic was known and controlled. Without specifying the
answer
> to (3), it isn't clear how the PCN domain can enforce the assumption
or
> monitor whether the assumption is being violated.)

I added a sentence in S3.2 (assumptions):
In other words we focus on PCN providing a benefit to inelastic traffic
(PCN may or may not provide a benefit to other types of traffic).

Your last sentence hopefully is covered by answer to point 3

> 
> 5. It's clear that the assumption in 3.5 is driven by encoding
> considerations. However, what is really unclear (to the naive reader
> such as myself) is why CE is problematic, but ECT(0/1) are not, since
> they all use the same IP header bits. If a packet in a PCN flow
arrives
> with ECT set, does that pass through the domain transparently? (It
would
> also be reassuring to state explicitly that ECN is transparent for
> non-PCN-flows.)

I adjusted S3.5 [hopefully deals with your next point too]:
What to do if a packet that is part of a PCN-flow arrives at a
PCN-ingress-node with its CE (Congestion experienced) codepoint set (or
if it detects that the ECN-nonce in use). There are several
possibilities (not discussed further in this document) about what the
PCN-ingress-node should do:
- drop the packet
- downgrade the packet to non PCN-BA, eg best effort
- tunnel the packet, so that the ECN-marking is carried transparently
across the PCN-domain.

> 
> 6. On the specific point about what to do with PCN flows using ECN, I
> can just about follow the logic
> - if CE was set, then it is possible that it was set by a router using
> the default ECN semantics
> - a router using the default ECN semantics should be able to assume
that
> the receiver would react in a similar way as to a packet drop
> - therefore the PCN domain can drop the packet
> However, it's quite a long journey from the beginning of the argument
to
> the end. In particular, for an endpoint, receiving a packet with CE is
> quite different from not receiving a packet at all. For one thing, it
> means the receiver gets data. It also gets a positive signal of
> congestion (rather than, for example, wondering whether it was a
> congestive or corruptive packet loss). In general, I think it's really
> important not to do things which act as deployment disincentives for
> ECN, or any additional barriers to alternative semantics, since e2e
> packet marking is so useful for congestion control in some
environments
> (multi-hop wireless in particular).
> 
> If the desire is to have a simple solution for PCN which uses the ECN
> bits for encoding, there might be an alternative: if you detect that a
> PCN-flow is using ECN (because ECT is set on any of its packets),
simply
> reclassify that flow as non-PCN and let it pass transparently through
> the domain as non-PCN (e.g. best efforts) traffic. In performance
terms
> the flow is getting no worse service than in a pre-PCN world. If you
> really think that there are no use cases for combined ECN/PCN this
> situation will never arise. If applications are developed in the
future
> which can exploit ECN for semi-elastic flows, then it becomes a
question
> of writing guidelines for application developers to help them either
> interpret signalling protocols (to find out whether their success in
> admission control is being harmed by their use of ECN) or split their
> flows into elastic and inelastic sub-flows, or indeed work out a PCN
> solution which didn't use the ECN bits internally. All of these would
> obviously be a later stage of the work.
> 
> cheers & have fun in vancouver,
> 
> robert h.
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn