Subject: [PCN] Some clarification questions about draft-westberg-pcn-load-control

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Thu, 26 Jul 2007 22:57:24 -0400

Hi Georgios and other authors of draft-westberg-pcn-load-control,

There is some confusion that surfaced during and after the PCN WG
meetings regarding the details of the algorithm operation, and which I
was not able to clarify by reading the draft. Here are some of the
questions that I would appreciate some clarification.

1) it is not clear how many configured rate thresholds is at the
internal nodes. The draft mentions congestion-detection-threshold,
severe_congestion_detection and severe_congestion_restoration. On the
other hand the presentation in Chicago (I believe) mentioned only two
thresholds.   

2) Another question related the thresholds. The draft does not appear to

define any explicit relationship between the two (three? See above) rate
thresholds other than describing which one is greater than the other.
However, if I understood Georgios correctly in the hallway conversation
in Chicago, it appears that it is implicitly assumed that in fact the
ratio between the two thresholds (which 2 of the three above?) is
assumed to be constant for all nodes in the network.  Is there indeed
such an assumption, or did I misunderstand something?

3) It is not entirely clear how many code points is actually needed by
the proposal.  The draft mentions in different places "local-DSCP",
"original-dscp", "encoded-dscp", "affected-DSCP" and "notified DSCP". Do
we really need 5 states for this approach?  Is it possible to clarify
which one is used for what?

4)section 4.1.2 says:
" the difference between the congestion notification threshold and the
engineered bandwidth limitation, i.e. admission threshold, provides an
interval where the signaling information on resource limitation is
already sent by a node but the actual limitation is not reached".  I do
not understand what this means. First - does it mean that there is one
more threshold ('engineered bandwidth limitation = admission rate' and
"congestion notification threshold"?  (if so, that brings various
thresholds mentioned in the draft to 4, counting also
severe-congestion-notification and severe-congestion-restoration???).
Second, what "signal" do you mean here?  Admission marking? Probe?
Termination marking?  Can you clarify please?

Next, one par below:  "To distinguish between congestion notification
and severe congestion, the following method is used: The "encoded DSCP"
marking for congestion notification and severe congestion. When this
method is used and when the interior node is in "congestion
notification" state, then the node should remark the unmarked bytes
using the "encoded DSCP".  

I am not sure I understand what the above means.  What is the "method"
you refer to? Do you just mean that some packets are marked with
"encoded dscp" when the measurement of the total rate at the internal
node exceeds the severe-congestion-? threshold (which
-severe-congestion-notification or severe-congestion-restoration)? 

5) There are two per-ingress-egress rate thresholds configured at each
*egress* (pre-configured congestion notification" threshold and
preconfigured severe congestion threshold).   How are these egress
thresholds chosen? Is there any relationship between these thresholds
and the corresponding thresholds at the internal nodes?  For example, is
there an assumption than the sum of the  (egress) severe congestion
notification thresholds of all ingress-egress-pairs sharing a bottleneck
link does not exceed the severe congestion notification threshold at
that bottleneck link?  

6) Section 4.1.3 says

When the egress receives the probe packet, which is used as a request
for reservation, it will have to perform the following  functionality.
When the operation state of the ingress/egress pair  aggregate is the
"congestion notification", see Section 4.2.3, then the implementation of
the algorithm depends on how the congestion notification situation is
notified to the egress. As mentioned in Section 4.1.2 this is
accomplished by using the received data packets that are marked using
the "encoded DSCP". In this case, during a measurement interval T, the
egress measures the input_notified_bytes by counting instead of the
"notified DSCP", the "encoded DSCP" bytes."

What exactly is "input_totified_bytes"? This is the first time this is
mentioned in the draft... Is it just the number of bytes marked with
"encoded DSCP"?  

I have many more questions on the draft, but I am hoping that perhaps
the answers to the above will be helpful in understanding the rest of
the draft and/or will provide useful input where clarification may be
needed for the next version of the draft.

It would also be helpful, if the next version of the draft either
directly uses pcn terminology, or at least provide the mapping where the
mapping is possible.  

Thank you,
Anna 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 29 Jul 2007 09:46:13 +0000

Hi Anna

Thank you very much for your remarks and questions!
We will try to address all the issues that you have addressed in the next
version of the draft!

Best regards,
Georgios