Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt

From: <[email-masked]>
Date: Thu, 7 Aug 2008 09:06:06 +0100

Currently updating architecture with various nits. 

Minor changes to reflect that
- baseline encoding is consensus, WG doc, stds track - also the idea of
Exptal encoding extensions which may use a 2nd dscp (but not any
particular ones agreed)

- the corrections to Traffic conditioning agreed to the marking
behaviour also means some minor changes to bits of architecture i-d. The
most significant is to add a bullet to S6.5 PCN-traffic - at least I
think we agreed this, please shout if we didn't:
o It is not advised to have non PCN-traffic that shares the same
capacity (on a link) as PCN-traffic, since it makes the PCN mechanisms
less accurate and so reduces PCN's ability to protect the QoS of
admitted PCN-flows. If there is such traffic, there needs to be a
mechanism to limit it. 

- Probing now in Appendix A, and deleted the 'third viewpoint'
(admission control based on the marking of a single packet like an RSVP
PATH msg. This isn't really probing, and in any case is already
mentioned in S6.1.

- minor changes to S9 Operations and management - mainly to reflect that
consensus on marking behaviour has simplified things so eg there are
fewer parameters to configure. 

Best wishes
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 15 July 2008 10:02
{ To: [email-masked]
{ Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt
{ 
{ I spotted a couple of small corrections needed:
{ 
{ In S6.2, Flow termination
{ Exactly how the flow termination decision is made will be defined
{    separately in informational documents.  At a high level several
{    approaches are proposed:
{ ...
{    o  Another approach monitors PCN-packets and terminates any
PCN-flow
{       with an excess-traffic-marked packet.  Compared with the
{       approaches above, PCN-marking needs to be done at a reduced rate
{       (every "s" bytes of excess traffic) otherwise far too much
traffic
{       would be terminated.
{ 
{ This bullet needs to be changed, as it's inconsistent with the
consensus
{ decisions about marking algorithm. The equivalent approach can be
{ achieved by randomly selecting some fraction of the marked packets for
{ termination (as in
http://tools.ietf.org/id/draft-menth-pcn-emft-00.txt)
{ 
{ In S2 Terminology
{ The last sentence of both PCN-threshold-rate & PCN-excess-rate
{ definitions needs to be deleted (they don't apply in the single
marking
{ case).
{ 
{ In addition I think it would be helpful to add a couple of pics to
{ illustrate what PCN-threshold-rate & PCN-excess-rate mean in terms of
{ when admission and termination are done. Similar to Fig 1 in
{
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08
{ -PCN-Comparison.pdf - one for the case with 3 encoding states, and one
{ for single marking.
{ 
{ phil
{ 
{ { -----Original Message-----
{ { From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ { [email-masked]
{ { Sent: 15 July 2008 08:31
{ { To: [email-masked]
{ { Subject: [PCN] New version of draft-ietf-pcn-architecture-04.txt
{ {
{ { I updated the Architecture draft.
{ {
{ { There are no major changes, but several more minor ones. These
mostly
{ { reflect the consensus call about PCN-marking (as reflected in
{ { [I-D.eardley-pcn-marking-behaviour]), and the current decisions
about
{ { encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding] and
{ { [I-D.moncaster-pcn-3-state-encoding]). I also did some slight
{ { re-structuring and editing to try and improve the clarity,
especially
{ of
{ { the introductory material and the High level architecture (where I
{ also
{ { added a sub-section on backwards compatibility with respect to
{ { [RFC4774]). I also took account of all the comments received on the
{ -03
{ { version (thanks for them)
{ {
{ { Comments welcome! - thanks,
{ { phil
{ {
{ { { -----Original Message-----
{ { { From: [email-masked] [mailto:[email-masked]] On Behalf
{ Of
{ { { [email-masked]
{ { { Sent: 14 July 2008 23:00
{ { { To: [email-masked]
{ { { Cc: [email-masked]
{ { { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt
{ { {
{ { { A New Internet-Draft is available from the on-line Internet-Drafts
{ { { directories.
{ { { This draft is a work item of the Congestion and Pre-Congestion
{ { { Notification Working Group of the IETF.
{ { {
{ { {
{ { { 	Title           : Pre-Congestion Notification Architecture
{ { { 	Author(s)       : P. Eardley
{ { { 	Filename        : draft-ietf-pcn-architecture-04.txt
{ { { 	Pages           : 52
{ { { 	Date            : 2008-07-14
{ { {
{ { { The purpose of this document is to describe a general architecture
{ { { for flow admission and termination based on pre-congestion
{ { { information in order to protect the quality of service of
{ established
{ { { inelastic flows within a single DiffServ domain.Status
{ { {
{ { { A URL for this Internet-Draft is:
{ { {
{ http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt
{ { {
{ { { Internet-Drafts are also available by anonymous FTP at:
{ { { ftp://ftp.ietf.org/internet-drafts/
{ { {
{ { { Below is the data which will enable a MIME compliant mail reader
{ { { implementation to automatically retrieve the ASCII version of the
{ { { Internet-Draft.
{ { _______________________________________________
{ { PCN mailing list
{ { [email-masked]
{ { https://www.ietf.org/mailman/listinfo/pcn
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Thu, 07 Aug 2008 10:38:50 +0200

Hi Phil,

> Exptal encoding extensions which may use a 2nd dscp (but not any
I'd appreciate if PSDM is mentioned as a clever extension of baseline 
encoding to accommodate two marking schemes by a single DSCP. I think 
this is equally important as extensions by additional DSCPs.

> PATH msg. This isn't really probing, and in any case is already
It is probing, but without extra traffic. Therefore, wherever this 
method is described in the document, it should be called a clever 
probing method. The appendix on probing should have a reference to S6.1 
where this clever kind of probing is described.

I recommend to introduce the terms admissible and supportable rate. They 
are needed to say what the "excess-rate-threshold" should be set to in 
case of single marking or CL. They are also useful to qualify the type 
of pre-congestion and overload independently of the PCN implementation. 
In one of your last emails you stated that the meaning of the 
"excess-rate-threshold" depends on SM or CL and the phrase "It's roughly 
that rate down to which flow termination should, if necessary, terminate 
already admitted flows." should be deleted from its definition.

http://www.ietf.org/mail-archive/web/pcn/current/msg01594.html
http://www.ietf.org/mail-archive/web/pcn/current/msg01595.html

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 7 Aug 2008 11:00:05 +0200

Hi Phil, hi Michael, 

[deleted text I don't comment]
> PATH msg. This isn't really probing, and in any case is already

[Michael] 

[Ruediger]
A RSVP Path message and similar NSIS messages are transport service 
signaling messages. We piggyback a clever probing mechanism on them, but 
they remain signaling messages. These messages MUST be sent by a 
service requesting entity, whether PCN is active within a domain or 
not and I don't think that changing the ECN codings of these messages 
changes their purpose significantly enough to justify a change in 
terminology.

The point I want to make is, that these messages are or may be present, 
whether the PCN WG decides to apply probing or not. My interpretation of 
"probing" is that special measurement traffic is created for 
the single and only purpose of probing. This definition isn't met by 
RSVP and NSIS signaling messages. So they shouldn't be called probes.

Of course the architecture should mention that a clever probing mechanism 
could be piggybacked on path coupled signaling messages.

Regards,

Ruediger

---

From: <[email-masked]>
Date: Thu, 7 Aug 2008 10:20:21 +0100

{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ Sent: 07 August 2008 09:39
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt
{ 
{ Hi Phil,
{ 
{ [email-masked] wrote:
{ > Currently updating architecture with various nits.
{ >
{ > Minor changes to reflect that
{ > - baseline encoding is consensus, WG doc, stds track - also the idea
of
{ > Exptal encoding extensions which may use a 2nd dscp (but not any
{ > particular ones agreed)
{ >
{ I'd appreciate if PSDM is mentioned as a clever extension of baseline
{ encoding to accommodate two marking schemes by a single DSCP. I think
{ this is equally important as extensions by additional DSCPs.
{ 

I'll mention it somewhere
Thanks
phil

---

From: Michael Menth <[email-masked]>
Date: Thu, 07 Aug 2008 11:23:13 +0200

Hi Rüdiger, hi Phil,

> RSVP and NSIS signaling messages. So they shouldn't be called probes.
Given your definition of probing I agree with you. But I don't agree 
with you on your definition of probing. My definition of probing is:

Admission control based on the marking feedback from packets that are 
associated with the requesting flow and were recently sent on the same 
path. Generation of extra traffic is not necessary when other traffic 
can be used for that purpose.

This definition covers all facets of probing mechanisms discussed so far 
and is sharp enough to distinguish probing from other feedback 
mechanisms based on ingress-egress-aggregates. It does not lead to the 
observed clashes when talking about various probe mechanisms. When 
signaling traffic is reused for probing, the signaling packets on which 
the AC decision is based become also probe packets, but they primarily 
remain signaling packets of course.

It might be useful to add this definition of probing to the terminology 
section.

Regards,

    Michael