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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 30 Nov 2007 10:53:18 -0000

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

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

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

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

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

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]
https://www1.ietf.org/mailman/listinfo/pcn