Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01

From: <[email-masked]>
Date: Tue, 14 Oct 2008 15:52:25 +0100

As promised I have uploaded a new version. I am aware there are a handful of typos and spelling mistakes that I noticed just after uploading. I will correct these in the next version. I am now pretty happy with almost all the text.

The key section for the WG to note is Appendix B where I have put in a couple of questions that I would welcome input on. 

The first of these is where to put the text (now set out as a table) about valid and invalid transitions at PCN nodes? Should this be part of the baseline encoding or should it be split between a new edge node behaviour document and Phil's marking behaviour.

The second question relates to how to best handle the unexpected presence of the EXP codepoint. There is a potential for this to happen during any partial deployment of an experimental encoding extension scheme. Whilst it would be best for an operator to ensure all nodes run the same encoding there is a chance this might not happen. The best solution as I see it is for the baseline scheme to treat EXP the same as NM but to raise a management alarm...

I have also highlighted another point in Appendix A which needs a decision: should we as a WG recommend that RFC3168 full functionality tunnels SHOULD NOT be used in a PCN-domain or would it be better to put our collective voices behind Bob's attempts to correct the anomalous behaviour of tunnels which he is currently trying to push through TSVWG (draft-briscoe-tsvwg-ecn-tunnel-01)

Toby

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 14 October 2008 15:35
To: Moncaster,T,Toby,CXR9 R
Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-01 

A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been successfuly submitted by T Moncaster and posted to the IETF repository.

Filename:	 draft-ietf-pcn-baseline-encoding
Revision:	 01
Title:		 Baseline Encoding and Transport of Pre-Congestion Information
Creation_date:	 2008-10-14
WG ID:		 pcn
Number_of_pages: 12

Abstract:
Pre-congestion notification (PCN) provides information to support
admission control and flow termination in order to protect the
Quality of Service of inelastic flows.  It does this by marking
packets when traffic load on a link is approaching or has exceeded a
threshold below the physical link rate.  This document specifies how
such marks are to be encoded into the IP header.  The baseline
encoding described here provides for only two PCN encoding states.
It is designed to be easily extended to provide more encoding states
but such schemes will be described in other documents.

The IETF Secretariat.

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

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 12:11:14 +0100

Toby,

Michael has brought up what I think is a good suggestion in the context
of the marking behaviour draft
http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-00 

{ ===================================================
{ 
{ Section 2.5
{ 
{ This section describes the required joint behavior of excess and
threshold
{ markers in specific deployment scenarios. Doing that in the main body
of
{ the documents sounds like excluding other use, e.g. for
packet-specific
{ dual
{ marking which allows the implementation of a CL-like admission control
and
{ flow termination with only a single DSCP. I suggest decoupling the
{ description
{ of the meter and marker functions from their joint behavior which
depends
{ on
{ the specific encoding.

I sympathise with michael's point. I'm inclined to think that most of
the current text in S2.5 of ietf-pcn-marking-behaviour-00 would fit
better in the baseline encoding draft. I think it would fit naturally
into your text about encoding transitions (current Appendix B). at the
moment the table just gives what the valid transitions are - this would
be expanded by saying in more detail which specific transitions are
valid depending on what the meters say.

In answer to your question about App B "The PCN working group needs to
decide whether to
   include this in this baseline encoding or whether to transfer it to
   an alternative document."
I think michael's point & PSDM example means that it needs to be
specified in each encoding document. You could say this in S5 (Rules for
Experimental Encoding Schemes) ie require extensions to specify
similarly what the encoding transitions are depending on the state of
the 2 meters.

phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 14 October 2008 15:52
{ To: [email-masked]
{ Subject: Re: [PCN] New Version Notification
fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ As promised I have uploaded a new version. I am aware there are a
handful
{ of typos and spelling mistakes that I noticed just after uploading. I
will
{ correct these in the next version. I am now pretty happy with almost
all
{ the text.
{ 
{ The key section for the WG to note is Appendix B where I have put in a
{ couple of questions that I would welcome input on.
{ 
{ The first of these is where to put the text (now set out as a table)
about
{ valid and invalid transitions at PCN nodes? Should this be part of the
{ baseline encoding or should it be split between a new edge node
behaviour
{ document and Phil's marking behaviour.
{ 
{ The second question relates to how to best handle the unexpected
presence
{ of the EXP codepoint. There is a potential for this to happen during
any
{ partial deployment of an experimental encoding extension scheme.
Whilst it
{ would be best for an operator to ensure all nodes run the same
encoding
{ there is a chance this might not happen. The best solution as I see it
is
{ for the baseline scheme to treat EXP the same as NM but to raise a
{ management alarm...
{ 
{ I have also highlighted another point in Appendix A which needs a
{ decision: should we as a WG recommend that RFC3168 full functionality
{ tunnels SHOULD NOT be used in a PCN-domain or would it be better to
put
{ our collective voices behind Bob's attempts to correct the anomalous
{ behaviour of tunnels which he is currently trying to push through
TSVWG
{ (draft-briscoe-tsvwg-ecn-tunnel-01)
{ 
{ Toby
{ 
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:[email-masked]]
{ Sent: 14 October 2008 15:35
{ To: Moncaster,T,Toby,CXR9 R
{ Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
{ Subject: New Version Notification for
draft-ietf-pcn-baseline-encoding-01
{ 
{ 
{ A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been
{ successfuly submitted by T Moncaster and posted to the IETF
repository.
{ 
{ Filename:	 draft-ietf-pcn-baseline-encoding
{ Revision:	 01
{ Title:		 Baseline Encoding and Transport of
Pre-Congestion
{ Information
{ Creation_date:	 2008-10-14
{ WG ID:		 pcn
{ Number_of_pages: 12
{ 
{ Abstract:
{ Pre-congestion notification (PCN) provides information to support
{ admission control and flow termination in order to protect the
{ Quality of Service of inelastic flows.  It does this by marking
{ packets when traffic load on a link is approaching or has exceeded a
{ threshold below the physical link rate.  This document specifies how
{ such marks are to be encoded into the IP header.  The baseline
{ encoding described here provides for only two PCN encoding states.
{ It is designed to be easily extended to provide more encoding states
{ but such schemes will be described in other documents.
{ 
{ 
{ 
{ The IETF Secretariat.
{ 
{ 
{ _______________________________________________
{ 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: Wed, 15 Oct 2008 15:07:18 +0200

Hi Phil,

I think you understood my point. I try to clarify a bit more what I and 
possibly you also mean.

Marking documents should cover only the individual behavior of the
markers and not reveal too many specifics about their exact
application in specific PCN deployment scenarios.
 Input: set of packets to be metered, set of packets to be marked
 Output: set of marked packets

The encoding documents should define the codepoints, explain their
semantics, and give constraints about their usage.

Documents about deployment scenarios should describe the behavior
of PCN nodes, the correct configuration of the markers and bind
their action to the specific encoding. This document should
give the glue, i.e. it tells how conditioning is done, which meters and
markers are used and configured with which reference rates, which 
packets are input
for the meters and markers, and how metering results are translated into
encodings.

There are two major possibilities for the description of a specific PCN 
architecture.

1. Provide marking and encoding drafts as generic building blocks. An 
additional document explains how they are used in a specific deployment 
scenario. There may be one deployment scenario or more, depending on 
whether a single one covers all needs. The current objective of the 
group is to define one deployment scenario and keep the door open for 
others just in case the one does not satisfy the application scenarios. 
That's at least my understanding.

2. Provide marking and encoding drafts as parts of a specific deployment 
scenario. This degrades readability of the documents and prevents simple 
extension of PCN since the building blocks are not generic and must be 
changed to describe alternative deployment scenarios.

Currently I see that the second path is taken because the marking draft 
contains a lot deployment specific assumptions. I don't know whether 
this happened intentionally or not.

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: <[email-masked]>
Date: Wed, 15 Oct 2008 14:21:42 +0100

{ 1. Provide marking and encoding drafts as generic building blocks. An
{ additional document explains how they are used in a specific
deployment
{ scenario. There may be one deployment scenario or more, depending on
{ whether a single one covers all needs. The current objective of the
{ group is to define one deployment scenario and keep the door open for
{ others just in case the one does not satisfy the application
scenarios.
{ That's at least my understanding.
{ 
{ 2. Provide marking and encoding drafts as parts of a specific
deployment
{ scenario. This degrades readability of the documents and prevents
simple
{ extension of PCN since the building blocks are not generic and must be
{ changed to describe alternative deployment scenarios.
{ 
{ Currently I see that the second path is taken because the marking
draft
{ contains a lot deployment specific assumptions. I don't know whether
{ this happened intentionally or not.
{ 

this wasn't intentional on my part. But I know this is something that I
have to make an effort to avoid, so would appreciate it if you could
point out places where the marking draft makes deployment specific
assumptions. Yes I agree the text in S2.5 does. App C also, but this
Appendix will be deleted in the next version (it's basically a reminder
to the WG that we seem to need a PDB doc, and we need someone to write
it (not me!))

thanks
phil

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 14:32:50 +0100

Hi Michael,

Thank you. This is a very clear description of the functional split
between the different documents that are needed for PCN. Unfortunately
at the moment we have a difficult situation where the split has not been
cleanly achieved. What is missing is the set of documents describing how
to collect all the pieces of PCN together into a working system. The
Architecture document is the basis for such documents but has had to
leave some options open to cater for the different possible deployment
scenarios.

As you correctly say we are currently nearer to your option 2. than your
option 1. This runs the risk of limiting us in future when we come to
expand PCN and also makes it harder to re-use PCN as a building block
for other systems.

There would seem to be 2 possible approaches we can take:

A) We improve the current structure by (for instance) merging the "how
it all works" bits as a Part B to the Encoding document. This is not the
best option as it slightly precludes the encoding documents from being
used for more general purposes in the future. Also the documents
describing how to assemble a system are most likely to be informational
whilst the encoding is standards track.

B) We find willing authors to take on the jobs of writing deployment
documents bringing together all the snippets of text that already exist
and creating a coherent whole from them. This would be a reasonably
straight-forward task but would require careful thought as there are a
number of sensible deployments that are possible currently. This is
pretty much what you describe in your option 2. 

Myself and Phil really have no time to write new documents for PCN so
the decision on which way to go depends on enough people volunteering to
write new documents. I can probably find time to assist with editing
such documents but can't take sole ownership...

Toby

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 15 October 2008 14:07
To: Eardley,PL,Philip,CXR9 R
Cc: Moncaster,T,Toby,CXR9 R; [email-masked]
Subject: Re: [PCN] New Version Notification
fordraft-ietf-pcn-baseline-encoding-01

Hi Phil,

Regards,

    Michael

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Oct 2008 08:46:00 +0200

Michael,

your proposal 1. below sounds better to me than proposal 2. To ensure useful 
standardisation results, the WG should define a PCN cookbook (a defined 
structure of a PCN realisation, the structure should be standards track) 
and provide at least on example of a PCN recipe (you call it deployment
scenario, should be informational - unless the WG succeeds in consenting on a 
single one).

I'm not sure, whether the architecture doc is that cookbook or is meant 
to become it. It may be a better idea to work with the architecture doc 
as a framework and later, after we have RFCs on coding, marking and so 
on, indicate how to build a PCN solution.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Wednesday, October 15, 2008 3:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01

Hi Phil,

Regards,

    Michael

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Oct 2008 08:47:26 +0200

Toby,

thanks for adding more content in the reviewed version. Apart from my 
support of Michaels proposal 1., I still would like to comment on 
some of your new text: 

Appendix B, Table 2, row "ingress"

If "PM" is an invalid codepoint out, then the ingress node does not 
belong to the PCN domain. As far as I understood, indication of 
pre-congestion on a link is signaled by a PM mark. The ingress 
node following your specification in row "ingress" however 
can't signal pre-congestion.

Specifying behaviours for unexpected codepoints is a necessity and 
writing down this requirement adds value to the document. The 
question is, whether forward compatibility benefits from handling 
EXP as NM. The whole topic is in fact a marking issue, and there
it should be dealt with. Thoughts on your proposal:
- Could a future extension exist, where there's no transition 
  from EXP to PM? Then your proposal is harmful.
- What you don't discuss, as you are writing the encoding draft,
  is whether the EXP packets should be metered by an interior 
  node just supporting baseline encoding. I think they should be. 
  But may be, I'm wrong and all of this discussion on receiving 
  packets with unexpected codings and backward/forward 
  compatibility should be a requirement for a PCN deployment 
  scenario document.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 14, 2008 4:52 PM
To: [email-masked]
Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01

Toby

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 14 October 2008 15:35
To: Moncaster,T,Toby,CXR9 R
Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-01 

Abstract:

The IETF Secretariat.

---

From: Michael Menth <[email-masked]>
Date: Tue, 21 Oct 2008 10:35:07 +0200

Hi Ruediger,

my thinking is what you also suspect at the end of your email: the 
description of the packets to be metered and the packets to be re-marked 
is part of the deployment model and meters and markers must be 
configurable with regard to this respect. The same applies to drop 
preferences. It does not mean that anything can be done in PCN. The 
restrictions come through the deployment models that say which building 
blocks MUST be used and how they MUST be configured. Then, metering and 
marking can be kept general and encoding does not need to know anything 
about its future use.

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 09:38:50 +0100

Hi Ruediger,

My argument for making PM an invalid transition for a PCN-ingress node
is that in my head I have a conceptual model that views the PCN region
as consisting of a number of nodes that do PCN marking surrounded by a
fence of PCN-boundary nodes. These boundary nodes simply control ingress
and egress from the region and don't actually do any marking. Of course
in practise the ingress and egress nodes would also have marking
functionality but it is easier to think of them as separate nodes.

As far as I know there is no current proposed extension where EXP can't
be marked to PM. Even in Bob's proposal with fully working tunnels EXP
could be remarked to PM. The question I had in my head was the other way
round: If we don't specify a behaviour for EXP in the baseline will
extension encodings still work if any nodes haven't been upgraded? The
answer to that seemed to be "no" for the majority of proposals (apart
from the simple variant of 3 state encoding).

As you say we also need to decide what to do with EXP packets regarding
metering. I think as currently written Phil's draft allows them to be
metered but I will check that with him.

Toby

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: 21 October 2008 07:47
To: Moncaster,T,Toby,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] New Version Notification

Toby,

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, October 14, 2008 4:52 PM
To: [email-masked]
Subject: Re: [PCN] New Version Notification
fordraft-ietf-pcn-baseline-encoding-01

As promised I have uploaded a new version. I am aware there are a
handful of typos and spelling mistakes that I noticed just after
uploading. I will correct these in the next version. I am now pretty
happy with almost all the text.

The key section for the WG to note is Appendix B where I have put in a
couple of questions that I would welcome input on. 

The first of these is where to put the text (now set out as a table)
about valid and invalid transitions at PCN nodes? Should this be part of
the baseline encoding or should it be split between a new edge node
behaviour document and Phil's marking behaviour.

The second question relates to how to best handle the unexpected
presence of the EXP codepoint. There is a potential for this to happen
during any partial deployment of an experimental encoding extension
scheme. Whilst it would be best for an operator to ensure all nodes run
the same encoding there is a chance this might not happen. The best
solution as I see it is for the baseline scheme to treat EXP the same as
NM but to raise a management alarm...

I have also highlighted another point in Appendix A which needs a
decision: should we as a WG recommend that RFC3168 full functionality
tunnels SHOULD NOT be used in a PCN-domain or would it be better to put
our collective voices behind Bob's attempts to correct the anomalous
behaviour of tunnels which he is currently trying to push through TSVWG
(draft-briscoe-tsvwg-ecn-tunnel-01)

Toby

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 14 October 2008 15:35
To: Moncaster,T,Toby,CXR9 R
Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
Subject: New Version Notification for

A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been
successfuly submitted by T Moncaster and posted to the IETF repository.

Filename:	 draft-ietf-pcn-baseline-encoding
Revision:	 01
Title:		 Baseline Encoding and Transport of Pre-Congestion
Information
Creation_date:	 2008-10-14
WG ID:		 pcn
Number_of_pages: 12

Abstract:

The IETF Secretariat.

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 10:16:47 +0100

{ 
{ As you say we also need to decide what to do with EXP packets
regarding
{ metering. I think as currently written Phil's draft allows them to be
{ metered but I will check that with him.
{ 

PCN-pkts with EXP encoding are still PCN-pkts. Therefore they MUST be
treated as a metered-pkt. 

Quotes from
http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-01 

   o  Metered-packet: a packet that is metered by the metering functions
      specified below.  A PCN-packet MUST be treated as a metered-packet
      (with the minor exception noted below in Section 2.4).  

   A PCN-node MUST classify a packet as a PCN-packet if the value of its
   DSCP and ECN fields correspond to a PCN-enabled codepoint, as defined
   in the encoding scheme applicable to the PCN-domain.  Otherwise the
   packet MUST NOT be classified as a PCN-packet.

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 10:29:23 +0100

{ 
{ my thinking is what you also suspect at the end of your email: the
{ description of the packets to be metered and the packets to be
re-marked
{ is part of the deployment model and meters and markers must be
{ configurable with regard to this respect. The same applies to drop
{ preferences. It does not mean that anything can be done in PCN. The
{ restrictions come through the deployment models that say which
building
{ blocks MUST be used and how they MUST be configured. Then, metering
and
{ marking can be kept general and encoding does not need to know
anything
{ about its future use.

I disagree with this to some extent. 

I think that what pkts are metered and what re-marked is something to be
standardised in the encoding drafts. This allows each to be carefully
thought about and for manufacturers to say that their kit is conformant
with a STD. putting this in a deployment model is not as good - there
will (assuming pcn's success) potentially be many deployment models, and
many deployment models based on a particular encoding. The framework is
that the behaviour of the interior nodes (in terms of both marking
behaviour & encoding) is simple and clear, without a whole lot of
configurable options. Meanwhile, there's more freedom in terms of the
behaviour of the gateways in how they interpret these marks. Of course
it may turn out that in practice there are only a couple of good sets of
gateway behaviour.
Anyway, I read your email as proposing that the marking and encoding
should allow lots of freedom with lots of configurable options, and that
the deployment models should be where things are standardised in anger.
I disagree with that.

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 10:37:17 +0100

My view is that this should be in the encoding drafts, as what
transitions are valid depends on the encoding (eg the answer would be
different for PSDM). However, I also think - since other encodings are
seen as extensions of the baseline encoding - that the baseline should
define what 'extensions' means - it presumably means that there are
restrictions on those other encodings in terms of what transitions are
valid, eg that 11 MUST correspond to some kind of PCN-marking. 

{ 

I think this is reasonable. 

{ 

'should we recommend...' - don't know.
'should we put our collective voices..' - yes.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Oct 2008 12:13:16 +0200

Phil,

my view is, that the coding and marking as they are specified right now are 
allright, but may have to be reduced to the bare functionality specified. 
Examples of deployment models and references to documents specifying them
could be given - but these should be teasers, no lengthy descriptions.

Separate documents may discuss different deployment models. There and only 
there, flexibility should be allowed. I also think, PCN should generally 
leave room for experimental extensions (like PCN sucessfully does eg. 
with experimental three codepoint marking schemes). 

A question coming to my mind is, whether we are able to consent on further 
standard ingress/egrees node functionalities apart from baseline coding 
and marking behaviour. Egress measurement functions is one such topic. 
The more such basic standard functionalities we can agree on, the better.

My general philosophy is: define a common starting point. Leave room to 
learn and adapt systems, once we all started from the common starting 
point. What I dislike, and I think we aggree on that, is parallel 
customisation of different solutions from start on. 

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 11:29 AM
To: [email-masked]; Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-encoding-01

{

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 11:36:26 +0100

{ -----Original Message-----
{ From: Geib, Ruediger [mailto:[email-masked]]
{ Sent: 21 October 2008 11:13
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Phil,
{ 
{ my view is, that the coding and marking as they are specified right now
{ are
{ allright, but may have to be reduced to the bare functionality specified.

Not sure what you mean, what needs reducing? (not sure if this is cutting out some of the MUSTS/SHOULDS or cutting some of the explanatory material)

{ Examples of deployment models and references to documents specifying them
{ could be given - but these should be teasers, no lengthy descriptions.
Yes

{ 
{ Separate documents may discuss different deployment models. There and only
{ there, flexibility should be allowed. I also think, PCN should generally
{ leave room for experimental extensions (like PCN sucessfully does eg.
{ with experimental three codepoint marking schemes).
Agree

{ 
{ A question coming to my mind is, whether we are able to consent on further
{ standard ingress/egrees node functionalities apart from baseline coding
{ and marking behaviour. Egress measurement functions is one such topic.
That's an interesting question. It would certainly be nice. Perhaps one that's easier to discuss f2f?

{ The more such basic standard functionalities we can agree on, the better.
{ 
{ My general philosophy is: define a common starting point. Leave room to
{ learn and adapt systems, once we all started from the common starting
{ point. What I dislike, and I think we aggree on that, is parallel
{ customisation of different solutions from start on.
Agree!

{ 
{ Regards,
{ 
{ Ruediger
{ 
{ 
{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]]
{ Sent: Tuesday, October 21, 2008 11:29 AM
{ To: [email-masked]; Geib, Rüdiger
{ Cc: [email-masked]
{ Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ {
{ { my thinking is what you also suspect at the end of your email: the
{ { description of the packets to be metered and the packets to be
{ re-marked
{ { is part of the deployment model and meters and markers must be
{ { configurable with regard to this respect. The same applies to drop
{ { preferences. It does not mean that anything can be done in PCN. The
{ { restrictions come through the deployment models that say which
{ building
{ { blocks MUST be used and how they MUST be configured. Then, metering
{ and
{ { marking can be kept general and encoding does not need to know
{ anything
{ { about its future use.
{ 
{ I disagree with this to some extent.
{ 
{ I think that what pkts are metered and what re-marked is something to be
{ standardised in the encoding drafts. This allows each to be carefully
{ thought about and for manufacturers to say that their kit is conformant
{ with a STD. putting this in a deployment model is not as good - there
{ will (assuming pcn's success) potentially be many deployment models, and
{ many deployment models based on a particular encoding. The framework is
{ that the behaviour of the interior nodes (in terms of both marking
{ behaviour & encoding) is simple and clear, without a whole lot of
{ configurable options. Meanwhile, there's more freedom in terms of the
{ behaviour of the gateways in how they interpret these marks. Of course
{ it may turn out that in practice there are only a couple of good sets of
{ gateway behaviour.
{ Anyway, I read your email as proposing that the marking and encoding
{ should allow lots of freedom with lots of configurable options, and that
{ the deployment models should be where things are standardised in anger.
{ I disagree with that.
{

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Oct 2008 13:12:51 +0200

Hi Phil, 

{ my view is, that the coding and marking as they are specified right now are
{ allright, but may have to be reduced to the bare functionality specified.

[Phil]:
Not sure what you mean, what needs reducing? (not sure if this is cutting out 
some of the MUSTS/SHOULDS or cutting some of the explanatory material)

[Ru]: 
On a general level if anything should be cut out, explanatory material (I may 
have review comments on content, but that's not what I'm talking about here).
Please also note that by the above I'm not critising your draft as containing 
not necessary information.

Regards, Rudiger

{ 

{ 

{ 
{ Regards,
{ 
{ Ruediger
{ 
{

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 12:20:59 +0100

Ok, - will wait for your comments on the marking draft 
Thanks!
phil

{ -----Original Message-----
{ From: Geib, Ruediger [mailto:[email-masked]]
{ Sent: 21 October 2008 12:13
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Hi Phil,
{ 
{ { my view is, that the coding and marking as they are specified right now
{ are
{ { allright, but may have to be reduced to the bare functionality
{ specified.
{ 
{ [Phil]:
{ Not sure what you mean, what needs reducing? (not sure if this is cutting
{ out
{ some of the MUSTS/SHOULDS or cutting some of the explanatory material)
{ 
{ [Ru]:
{ On a general level if anything should be cut out, explanatory material (I
{ may
{ have review comments on content, but that's not what I'm talking about
{ here).
{ Please also note that by the above I'm not critising your draft as
{ containing
{ not necessary information.
{ 
{ Regards, Rudiger
{ 
{ 
{ 
{ 
{ { Examples of deployment models and references to documents specifying
{ them
{ { could be given - but these should be teasers, no lengthy descriptions.
{ Yes
{ 
{ {
{ { Separate documents may discuss different deployment models. There and
{ only
{ { there, flexibility should be allowed. I also think, PCN should generally
{ { leave room for experimental extensions (like PCN sucessfully does eg.
{ { with experimental three codepoint marking schemes).
{ Agree
{ 
{ {
{ { A question coming to my mind is, whether we are able to consent on
{ further
{ { standard ingress/egrees node functionalities apart from baseline coding
{ { and marking behaviour. Egress measurement functions is one such topic.
{ That's an interesting question. It would certainly be nice. Perhaps one
{ that's easier to discuss f2f?
{ 
{ { The more such basic standard functionalities we can agree on, the
{ better.
{ {
{ { My general philosophy is: define a common starting point. Leave room to
{ { learn and adapt systems, once we all started from the common starting
{ { point. What I dislike, and I think we aggree on that, is parallel
{ { customisation of different solutions from start on.
{ Agree!
{ 
{ {
{ { Regards,
{ {
{ { Ruediger
{ {
{ {
{ { -----Original Message-----
{ { From: [email-masked] [mailto:[email-masked]]
{ { Sent: Tuesday, October 21, 2008 11:29 AM
{ { To: [email-masked]; Geib, Rüdiger
{ { Cc: [email-masked]
{ { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ { encoding-01
{ {
{ { {
{ { { my thinking is what you also suspect at the end of your email: the
{ { { description of the packets to be metered and the packets to be
{ { re-marked
{ { { is part of the deployment model and meters and markers must be
{ { { configurable with regard to this respect. The same applies to drop
{ { { preferences. It does not mean that anything can be done in PCN. The
{ { { restrictions come through the deployment models that say which
{ { building
{ { { blocks MUST be used and how they MUST be configured. Then, metering
{ { and
{ { { marking can be kept general and encoding does not need to know
{ { anything
{ { { about its future use.
{ {
{ { I disagree with this to some extent.
{ {
{ { I think that what pkts are metered and what re-marked is something to be
{ { standardised in the encoding drafts. This allows each to be carefully
{ { thought about and for manufacturers to say that their kit is conformant
{ { with a STD. putting this in a deployment model is not as good - there
{ { will (assuming pcn's success) potentially be many deployment models, and
{ { many deployment models based on a particular encoding. The framework is
{ { that the behaviour of the interior nodes (in terms of both marking
{ { behaviour & encoding) is simple and clear, without a whole lot of
{ { configurable options. Meanwhile, there's more freedom in terms of the
{ { behaviour of the gateways in how they interpret these marks. Of course
{ { it may turn out that in practice there are only a couple of good sets of
{ { gateway behaviour.
{ { Anyway, I read your email as proposing that the marking and encoding
{ { should allow lots of freedom with lots of configurable options, and that
{ { the deployment models should be where things are standardised in anger.
{ { I disagree with that.
{ {

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 13:50:51 +0100

I don't know if it is what Phil is doing but personally my approach in the encoding draft has been to include explanatory text whilst the document matures with the intention of then removing most of the explanation once the document becomes ready to be last-called and moved to RFC.

Toby

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Oct 2008 15:32:53 +0200

Hi Toby,

Appendix B of your actual draft caused some controversy. Is it intended to 
be normative (don't recall what your text says) or just raising attention 
to some topics to be discussed? 

The appendix free version of your draft is well written, if it comes to me.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2008 2:51 PM
To: [email-masked]; Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-encoding-01

Toby

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 15:32:30 +0100

For the marking behaviour draft, both the Appendices are Informative. App A is examples of algos that meet the std. app B is explanation /discussion /comments on the std. Whether or not it's worth keeping either of them in the actual rfc, I don't have a particular view on. Personally I like to see the reasons for things, but I suppose this could always be done by reference (the rfc could say something like "see the I-D App B for explanations"???)

For App B of the encoding draft, my view is that this should be normative (not yet studied whether I agree with all the content)
{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Geib, Ruediger
{ Sent: 21 October 2008 14:33
{ To: Moncaster,T,Toby,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Hi Toby,
{ 
{ Appendix B of your actual draft caused some controversy. Is it intended to
{ be normative (don't recall what your text says) or just raising attention
{ to some topics to be discussed?
{ 
{ The appendix free version of your draft is well written, if it comes to
{ me.
{ 
{ Regards,
{ 
{ Ruediger
{ 
{ 
{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]]
{ Sent: Tuesday, October 21, 2008 2:51 PM
{ To: [email-masked]; Geib, Rüdiger
{ Cc: [email-masked]
{ Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ I don't know if it is what Phil is doing but personally my approach in the
{ encoding draft has been to include explanatory text whilst the document
{ matures with the intention of then removing most of the explanation once
{ the document becomes ready to be last-called and moved to RFC.
{ 
{ Toby
{ 
{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 21 October 2008 12:21
{ To: [email-masked]
{ Cc: [email-masked]
{ Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Ok, - will wait for your comments on the marking draft
{ Thanks!
{ phil
{ 
{ { -----Original Message-----
{ { From: Geib, Ruediger [mailto:[email-masked]]
{ { Sent: 21 October 2008 12:13
{ { To: Eardley,PL,Philip,CXR9 R
{ { Cc: [email-masked]
{ { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ { encoding-01
{ {
{ { Hi Phil,
{ {
{ { { my view is, that the coding and marking as they are specified right
{ now
{ { are
{ { { allright, but may have to be reduced to the bare functionality
{ { specified.
{ {
{ { [Phil]:
{ { Not sure what you mean, what needs reducing? (not sure if this is
{ cutting
{ { out
{ { some of the MUSTS/SHOULDS or cutting some of the explanatory material)
{ {
{ { [Ru]:
{ { On a general level if anything should be cut out, explanatory material
{ (I
{ { may
{ { have review comments on content, but that's not what I'm talking about
{ { here).
{ { Please also note that by the above I'm not critising your draft as
{ { containing
{ { not necessary information.
{ {
{ { Regards, Rudiger
{ {
{ {
{ {
{ {
{ { { Examples of deployment models and references to documents specifying
{ { them
{ { { could be given - but these should be teasers, no lengthy descriptions.
{ { Yes
{ {
{ { {
{ { { Separate documents may discuss different deployment models. There and
{ { only
{ { { there, flexibility should be allowed. I also think, PCN should
{ generally
{ { { leave room for experimental extensions (like PCN sucessfully does eg.
{ { { with experimental three codepoint marking schemes).
{ { Agree
{ {
{ { {
{ { { A question coming to my mind is, whether we are able to consent on
{ { further
{ { { standard ingress/egrees node functionalities apart from baseline
{ coding
{ { { and marking behaviour. Egress measurement functions is one such topic.
{ { That's an interesting question. It would certainly be nice. Perhaps one
{ { that's easier to discuss f2f?
{ {
{ { { The more such basic standard functionalities we can agree on, the
{ { better.
{ { {
{ { { My general philosophy is: define a common starting point. Leave room
{ to
{ { { learn and adapt systems, once we all started from the common starting
{ { { point. What I dislike, and I think we aggree on that, is parallel
{ { { customisation of different solutions from start on.
{ { Agree!
{ {
{ { {
{ { { Regards,
{ { {
{ { { Ruediger
{ { {
{ { {
{ { { -----Original Message-----
{ { { From: [email-masked] [mailto:[email-masked]]
{ { { Sent: Tuesday, October 21, 2008 11:29 AM
{ { { To: [email-masked]; Geib, Rüdiger
{ { { Cc: [email-masked]
{ { { Subject: RE: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ { { encoding-01
{ { {
{ { { {
{ { { { my thinking is what you also suspect at the end of your email: the
{ { { { description of the packets to be metered and the packets to be
{ { { re-marked
{ { { { is part of the deployment model and meters and markers must be
{ { { { configurable with regard to this respect. The same applies to drop
{ { { { preferences. It does not mean that anything can be done in PCN. The
{ { { { restrictions come through the deployment models that say which
{ { { building
{ { { { blocks MUST be used and how they MUST be configured. Then, metering
{ { { and
{ { { { marking can be kept general and encoding does not need to know
{ { { anything
{ { { { about its future use.
{ { {
{ { { I disagree with this to some extent.
{ { {
{ { { I think that what pkts are metered and what re-marked is something to
{ be
{ { { standardised in the encoding drafts. This allows each to be carefully
{ { { thought about and for manufacturers to say that their kit is
{ conformant
{ { { with a STD. putting this in a deployment model is not as good - there
{ { { will (assuming pcn's success) potentially be many deployment models,
{ and
{ { { many deployment models based on a particular encoding. The framework
{ is
{ { { that the behaviour of the interior nodes (in terms of both marking
{ { { behaviour & encoding) is simple and clear, without a whole lot of
{ { { configurable options. Meanwhile, there's more freedom in terms of the
{ { { behaviour of the gateways in how they interpret these marks. Of course
{ { { it may turn out that in practice there are only a couple of good sets
{ of
{ { { gateway behaviour.
{ { { Anyway, I read your email as proposing that the marking and encoding
{ { { should allow lots of freedom with lots of configurable options, and
{ that
{ { { the deployment models should be where things are standardised in
{ anger.
{ { { I disagree with that.
{ { {
{ 
{ _______________________________________________
{ 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: <[email-masked]>
Date: Tue, 21 Oct 2008 16:23:54 +0100

The appendices are meant to be informative and will either disappear in the final version or will move to a different document. Appendix A will go completely as it will just reference Bob's work on tunnelling, Appendix B will be partially incorporated (in response to WG responses to the questions I put in there) and Appendix C will be probably be replaced with a future deployment model draft(s).

Toby

---

From: Michael Menth <[email-masked]>
Date: Tue, 21 Oct 2008 18:22:24 +0200

Hi Phil,

yes, you are right. My example was ill-conceived. Currently I cannot 
think either of a sensible deployment model that would not meter all PCN 
packets for threshold marking and all unmarked PCN packets for excess 
marking.

My comment actually concerns the dropping behavior. Its definition in 
the marking draft unnecessarily constrains the use of the meters and 
markers and should be rather defined by deployment models.

Of course, only sensible freedom should be allowed in the marking and 
encoding draft. What sensible freedom is depends on which deployment 
models should be able to be basically supported. Now or possibly in the 
future.

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Oct 2008 10:37:29 +0200

Hi Phil,

the issue is whether the marking draft should also restrict drop 
preferences. Dropping of marked packets is not needed from a general 
marking perspective. It's only needed for indirect measured rate 
termination which is only one termination option out of many others. 
Requiring preferential dropping of special packets only limits the 
number of options of what you can do with PCN marking. Therefore, such 
constraints are better suitable for deployment models.

Regards,

    Michael

[email-masked] wrote:
> The thing is that we discussed dropping quite a lot at/near the ietf in
> Philadelphia, and the preferential dropping v reaction times argument.
> not that it's impossible to re-visit the decision, but is there new
> evidence or argument?
>
> phil
>
> { From: Michael Menth [mailto:[email-masked]]
> { Sent: 21 October 2008 17:22
> { Cc: [email-masked]; [email-masked]
> { Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
> { encoding-01
> { 
> { Hi Phil,
> { 
> { yes, you are right. My example was ill-conceived. Currently I cannot
> { think either of a sensible deployment model that would not meter all
> PCN
> { packets for threshold marking and all unmarked PCN packets for excess
> { marking.
> { 
> { My comment actually concerns the dropping behavior. Its definition in
> { the marking draft unnecessarily constrains the use of the meters and
> { markers and should be rather defined by deployment models.
> { 
> { Of course, only sensible freedom should be allowed in the marking and
> { encoding draft. What sensible freedom is depends on which deployment
> { models should be able to be basically supported. Now or possibly in
> the
> { future.
> { 
> { Regards,
> { 
> {     Michael
> { 
> { 
> { [email-masked] wrote:
> { > {
> { > { my thinking is what you also suspect at the end of your email: the
> { > { description of the packets to be metered and the packets to be
> { > re-marked
> { > { is part of the deployment model and meters and markers must be
> { > { configurable with regard to this respect. The same applies to drop
> { > { preferences. It does not mean that anything can be done in PCN.
> The
> { > { restrictions come through the deployment models that say which
> { > building
> { > { blocks MUST be used and how they MUST be configured. Then,
> metering
> { > and
> { > { marking can be kept general and encoding does not need to know
> { > anything
> { > { about its future use.
> { >
> { > I disagree with this to some extent.
> { >
> { > I think that what pkts are metered and what re-marked is something
> to be
> { > standardised in the encoding drafts. This allows each to be
> carefully
> { > thought about and for manufacturers to say that their kit is
> conformant
> { > with a STD. putting this in a deployment model is not as good -
> there
> { > will (assuming pcn's success) potentially be many deployment models,
> and
> { > many deployment models based on a particular encoding. The framework
> is
> { > that the behaviour of the interior nodes (in terms of both marking
> { > behaviour & encoding) is simple and clear, without a whole lot of
> { > configurable options. Meanwhile, there's more freedom in terms of
> the
> { > behaviour of the gateways in how they interpret these marks. Of
> course
> { > it may turn out that in practice there are only a couple of good
> sets of
> { > gateway behaviour.
> { > Anyway, I read your email as proposing that the marking and encoding
> { > should allow lots of freedom with lots of configurable options, and
> that
> { > the deployment models should be where things are standardised in
> anger.
> { > I disagree with that.
> { >
> { 
> { --
> { 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: <[email-masked]>
Date: Wed, 22 Oct 2008 09:12:53 +0100

phil

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Oct 2008 10:52:16 +0200

Hi Phil,

you ask for arguments and new evidence that indirect measured rate 
termination (IMRT), which is the only termination method that works well 
with preferential dropping of marked packets, is not sufficient. Just 
see IV.C of
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf
Certainly, workarounds can be provided to reduce the likelihood of 
overtermination with IMRT, but they make it even more complex and extend 
its reaction time. Therefore, I do not find it a good idea to rule out 
other termination methods by integrating an unnecessary constraints in 
the marking draft. There are other termination methods that are also 
fast even in the presence of packet loss, simpler to build, work with 
multipath routing, and do not suffer from this source of 
overtermination. Evidence is given in that paper or also in
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf

Regards,

    Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 22 Oct 2008 10:54:49 +0200

Hi all

I agree with Michael that such constraints are better suitable for 
deployment models.

Best regards,
Georgios

> Sent: woensdag 22 oktober 2008 10:37
> the issue is whether the marking draft should also restrict 
> drop preferences. Dropping of marked packets is not needed 
> from a general marking perspective. It's only needed for 
> indirect measured rate termination which is only one 
> termination option out of many others. 
> Requiring preferential dropping of special packets only 
> limits the number of options of what you can do with PCN 
> marking. Therefore, such constraints are better suitable for 
> deployment models.
> 
> Regards,
> 
>     Michael
> 
> > The thing is that we discussed dropping quite a lot at/near 
> the ietf 
> > in Philadelphia, and the preferential dropping v reaction 
> times argument.
> > { Cc: [email-masked]; [email-masked] { Subject: 
> Re: [PCN] 
> > New VersionNotification fordraft-ietf-pcn-baseline- { 
> encoding-01 { { 
> > Hi Phil, { { yes, you are right. My example was ill-conceived. 
> > Currently I cannot { think either of a sensible deployment 
> model that 
> > would not meter all PCN { packets for threshold marking and all 
> > unmarked PCN packets for excess { marking.
> > {
> > { My comment actually concerns the dropping behavior. Its 
> definition 
> > in { the marking draft unnecessarily constrains the use of 
> the meters 
> > and { markers and should be rather defined by deployment models.
> > {
> > { Of course, only sensible freedom should be allowed in the marking 
> > and { encoding draft. What sensible freedom is depends on which 
> > deployment { models should be able to be basically 
> supported. Now or 
> > possibly in the { future.
> > {
> > { Regards,
> > { 
> > {     Michael
> > {
> > {
> > { > { my thinking is what you also suspect at the end of 
> your email: 
> > the { > { description of the packets to be metered and the 
> packets to 
> > be { > re-marked { > { is part of the deployment model and 
> meters and 
> > markers must be { > { configurable with regard to this respect. The 
> > same applies to drop { > { preferences. It does not mean 
> that anything 
> > can be done in PCN.
> > The
> > { > { restrictions come through the deployment models that 
> say which { 
> > > building { > { blocks MUST be used and how they MUST be 
> configured. 
> > Then, metering { > and { > { marking can be kept general 
> and encoding 
> > does not need to know { > anything { > { about its future use.
> > { >
> > to be { > standardised in the encoding drafts. This allows 
> each to be 
> > carefully { > thought about and for manufacturers to say that their 
> > kit is conformant { > with a STD. putting this in a 
> deployment model 
> > is not as good - there { > will (assuming pcn's success) 
> potentially 
> > be many deployment models, and { > many deployment models 
> based on a 
> > particular encoding. The framework is { > that the behaviour of the 
> > interior nodes (in terms of both marking { > behaviour & 
> encoding) is 
> > simple and clear, without a whole lot of { > configurable options. 
> > Meanwhile, there's more freedom in terms of the { > 
> behaviour of the 
> > gateways in how they interpret these marks. Of course { > 
> it may turn 
> > out that in practice there are only a couple of good sets of { > 
> > gateway behaviour.
> > { > Anyway, I read your email as proposing that the marking and 
> > encoding { > should allow lots of freedom with lots of configurable 
> > options, and that { > the deployment models should be where 
> things are 
> > standardised in anger.
> > { 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]
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 10:04:15 +0100

I'll look at that and see what's new compared with what we discussed
before. Thanks. I probs wont have time to do that until the flight to
Minn.

{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ Sent: 22 October 2008 09:52
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] New VersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Hi Phil,
{ 
{ you ask for arguments and new evidence that indirect measured rate
{ termination (IMRT), which is the only termination method that works
well
{ with preferential dropping of marked packets, is not sufficient. Just
{ see IV.C of
{ http://www3.informatik.uni-
{ wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf
{ Certainly, workarounds can be provided to reduce the likelihood of
{ overtermination with IMRT, but they make it even more complex and
extend
{ its reaction time. Therefore, I do not find it a good idea to rule out
{ other termination methods by integrating an unnecessary constraints in
{ the marking draft. There are other termination methods that are also
{ fast even in the presence of packet loss, simpler to build, work with
{ multipath routing, and do not suffer from this source of
{ overtermination. Evidence is given in that paper or also in
{ http://www3.informatik.uni-
{ wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf
{ 
{ Regards,
{ 
{     Michael
{ 
{ [email-masked] wrote:
{ > The thing is that we discussed dropping quite a lot at/near the ietf
in
{ > Philadelphia, and the preferential dropping v reaction times
argument.
{ > not that it's impossible to re-visit the decision, but is there new
{ > evidence or argument?
{ >
{ > phil
{ >
{ > { -----Original Message-----
{ > { From: Michael Menth [mailto:[email-masked]]
{ > { Sent: 21 October 2008 17:22
{ > { To: Eardley,PL,Philip,CXR9 R
{ > { Cc: [email-masked]; [email-masked]
{ > { Subject: Re: [PCN] New VersionNotification
fordraft-ietf-pcn-baseline-
{ > { encoding-01
{ > {
{ > { Hi Phil,
{ > {
{ > { yes, you are right. My example was ill-conceived. Currently I
cannot
{ > { think either of a sensible deployment model that would not meter
all
{ > PCN
{ > { packets for threshold marking and all unmarked PCN packets for
excess
{ > { marking.
{ > {
{ > { My comment actually concerns the dropping behavior. Its definition
in
{ > { the marking draft unnecessarily constrains the use of the meters
and
{ > { markers and should be rather defined by deployment models.
{ > {
{ > { Of course, only sensible freedom should be allowed in the marking
and
{ > { encoding draft. What sensible freedom is depends on which
deployment
{ > { models should be able to be basically supported. Now or possibly
in
{ > the
{ > { future.
{ > {
{ > { Regards,
{ > {
{ > {     Michael
{ > {
{ > {
{ > { [email-masked] wrote:
{ > { > {
{ > { > { my thinking is what you also suspect at the end of your email:
the
{ > { > { description of the packets to be metered and the packets to be
{ > { > re-marked
{ > { > { is part of the deployment model and meters and markers must be
{ > { > { configurable with regard to this respect. The same applies to
drop
{ > { > { preferences. It does not mean that anything can be done in
PCN.
{ > The
{ > { > { restrictions come through the deployment models that say which
{ > { > building
{ > { > { blocks MUST be used and how they MUST be configured. Then,
{ > metering
{ > { > and
{ > { > { marking can be kept general and encoding does not need to know
{ > { > anything
{ > { > { about its future use.
{ > { >
{ > { > I disagree with this to some extent.
{ > { >
{ > { > I think that what pkts are metered and what re-marked is
something
{ > to be
{ > { > standardised in the encoding drafts. This allows each to be
{ > carefully
{ > { > thought about and for manufacturers to say that their kit is
{ > conformant
{ > { > with a STD. putting this in a deployment model is not as good -
{ > there
{ > { > will (assuming pcn's success) potentially be many deployment
models,
{ > and
{ > { > many deployment models based on a particular encoding. The
framework
{ > is
{ > { > that the behaviour of the interior nodes (in terms of both
marking
{ > { > behaviour & encoding) is simple and clear, without a whole lot
of
{ > { > configurable options. Meanwhile, there's more freedom in terms
of
{ > the
{ > { > behaviour of the gateways in how they interpret these marks. Of
{ > course
{ > { > it may turn out that in practice there are only a couple of good
{ > sets of
{ > { > gateway behaviour.
{ > { > Anyway, I read your email as proposing that the marking and
encoding
{ > { > should allow lots of freedom with lots of configurable options,
and
{ > that
{ > { > the deployment models should be where things are standardised in
{ > anger.
{ > { > I disagree with that.
{ > { >
{ > {
{ > { --
{ > { 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
{ >
{ 
{ --
{ 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: <[email-masked]>
Date: Wed, 22 Oct 2008 10:06:12 +0100

Remember that such choice adds complexity to the router, the
standardisation and the operation. 

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 22 October 2008 09:55
{ To: [email-masked]; Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: RE: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Hi all
{ 
{ I agree with Michael that such constraints are better suitable for
{ deployment models.
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of Michael Menth
{ > Sent: woensdag 22 oktober 2008 10:37
{ > To: [email-masked]
{ > Cc: [email-masked]
{ > Subject: Re: [PCN] NewVersionNotification
{ > fordraft-ietf-pcn-baseline-encoding-01
{ >
{ > Hi Phil,
{ >
{ > the issue is whether the marking draft should also restrict
{ > drop preferences. Dropping of marked packets is not needed
{ > from a general marking perspective. It's only needed for
{ > indirect measured rate termination which is only one
{ > termination option out of many others.
{ > Requiring preferential dropping of special packets only
{ > limits the number of options of what you can do with PCN
{ > marking. Therefore, such constraints are better suitable for
{ > deployment models.
{ >
{ > Regards,
{ >
{ >     Michael
{ >
{ > [email-masked] wrote:
{ > > The thing is that we discussed dropping quite a lot at/near
{ > the ietf
{ > > in Philadelphia, and the preferential dropping v reaction
{ > times argument.
{ > > not that it's impossible to re-visit the decision, but is there
new
{ > > evidence or argument?
{ > >
{ > > phil
{ > >
{ > > { -----Original Message-----
{ > > { From: Michael Menth [mailto:[email-masked]]
{ > > { Sent: 21 October 2008 17:22
{ > > { To: Eardley,PL,Philip,CXR9 R
{ > > { Cc: [email-masked]; [email-masked] { Subject:
{ > Re: [PCN]
{ > > New VersionNotification fordraft-ietf-pcn-baseline- {
{ > encoding-01 { {
{ > > Hi Phil, { { yes, you are right. My example was ill-conceived.
{ > > Currently I cannot { think either of a sensible deployment
{ > model that
{ > > would not meter all PCN { packets for threshold marking and all
{ > > unmarked PCN packets for excess { marking.
{ > > {
{ > > { My comment actually concerns the dropping behavior. Its
{ > definition
{ > > in { the marking draft unnecessarily constrains the use of
{ > the meters
{ > > and { markers and should be rather defined by deployment models.
{ > > {
{ > > { Of course, only sensible freedom should be allowed in the
marking
{ > > and { encoding draft. What sensible freedom is depends on which
{ > > deployment { models should be able to be basically
{ > supported. Now or
{ > > possibly in the { future.
{ > > {
{ > > { Regards,
{ > > {
{ > > {     Michael
{ > > {
{ > > {
{ > > { [email-masked] wrote:
{ > > { > {
{ > > { > { my thinking is what you also suspect at the end of
{ > your email:
{ > > the { > { description of the packets to be metered and the
{ > packets to
{ > > be { > re-marked { > { is part of the deployment model and
{ > meters and
{ > > markers must be { > { configurable with regard to this respect.
The
{ > > same applies to drop { > { preferences. It does not mean
{ > that anything
{ > > can be done in PCN.
{ > > The
{ > > { > { restrictions come through the deployment models that
{ > say which {
{ > > > building { > { blocks MUST be used and how they MUST be
{ > configured.
{ > > Then, metering { > and { > { marking can be kept general
{ > and encoding
{ > > does not need to know { > anything { > { about its future use.
{ > > { >
{ > > { > I disagree with this to some extent.
{ > > { >
{ > > { > I think that what pkts are metered and what re-marked
{ > is something
{ > > to be { > standardised in the encoding drafts. This allows
{ > each to be
{ > > carefully { > thought about and for manufacturers to say that
their
{ > > kit is conformant { > with a STD. putting this in a
{ > deployment model
{ > > is not as good - there { > will (assuming pcn's success)
{ > potentially
{ > > be many deployment models, and { > many deployment models
{ > based on a
{ > > particular encoding. The framework is { > that the behaviour of
the
{ > > interior nodes (in terms of both marking { > behaviour &
{ > encoding) is
{ > > simple and clear, without a whole lot of { > configurable options.
{ > > Meanwhile, there's more freedom in terms of the { >
{ > behaviour of the
{ > > gateways in how they interpret these marks. Of course { >
{ > it may turn
{ > > out that in practice there are only a couple of good sets of { >
{ > > gateway behaviour.
{ > > { > Anyway, I read your email as proposing that the marking and
{ > > encoding { > should allow lots of freedom with lots of
configurable
{ > > options, and that { > the deployment models should be where
{ > things are
{ > > standardised in anger.
{ > > { > I disagree with that.
{ > > { >
{ > > {
{ > > { --
{ > > { 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
{ > >
{ >
{ > --
{ > 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
{ >
{ > _______________________________________________
{ > PCN mailing list
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn
{ >
{

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Oct 2008 11:13:05 +0200

Hi Phil,

I agree with you that the number of standardized deployment models 
should be kept to a minimum and to simplify deployment. However, the 
complexity of configuration, standardization, and operation rather 
depends on the complexity of the deployment model itself and there are 
large differences. I don't believe that this issue has been understood 
very well so far.

Regards,

    Michael

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 13:57:18 +0100

The marking draft at the moment gives very low complexity of interior
nodes and their configuration, eg parameters are the threshold-rate &
excess-traffic-rate. Complexity of the boundary nodes is something that
we understand less well. I see the deployment model as being about the
boundary node behaviour, where it's appropriate to have a bit of freedom
in terms of >1 different (EXP) behaviours. 
{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ Sent: 22 October 2008 10:13
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]; [email-masked]
{ Subject: Re: [PCN] NewVersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Hi Phil,
{ 
{ I agree with you that the number of standardized deployment models
{ should be kept to a minimum and to simplify deployment. However, the
{ complexity of configuration, standardization, and operation rather
{ depends on the complexity of the deployment model itself and there are
{ large differences. I don't believe that this issue has been understood
{ very well so far.
{ 
{ Regards,
{ 
{     Michael
{ 
{ [email-masked] wrote:
{ > Remember that such choice adds complexity to the router, the
{ > standardisation and the operation.
{ >
{ > { -----Original Message-----
{ > { From: Georgios Karagiannis [mailto:[email-masked]]
{ > { Sent: 22 October 2008 09:55
{ > { To: [email-masked]; Eardley,PL,Philip,CXR9 R
{ > { Cc: [email-masked]
{ > { Subject: RE: [PCN] NewVersionNotification
fordraft-ietf-pcn-baseline-
{ > { encoding-01
{ > {
{ > { Hi all
{ > {
{ > { I agree with Michael that such constraints are better suitable for
{ > { deployment models.
{ > {
{ > { Best regards,
{ > { Georgios
{ > {
{ > {
{ > { > -----Original Message-----
{ > { > From: [email-masked] [mailto:[email-masked]] On
{ > { > Behalf Of Michael Menth
{ > { > Sent: woensdag 22 oktober 2008 10:37
{ > { > To: [email-masked]
{ > { > Cc: [email-masked]
{ > { > Subject: Re: [PCN] NewVersionNotification
{ > { > fordraft-ietf-pcn-baseline-encoding-01
{ > { >
{ > { > Hi Phil,
{ > { >
{ > { > the issue is whether the marking draft should also restrict
{ > { > drop preferences. Dropping of marked packets is not needed
{ > { > from a general marking perspective. It's only needed for
{ > { > indirect measured rate termination which is only one
{ > { > termination option out of many others.
{ > { > Requiring preferential dropping of special packets only
{ > { > limits the number of options of what you can do with PCN
{ > { > marking. Therefore, such constraints are better suitable for
{ > { > deployment models.
{ > { >
{ > { > Regards,
{ > { >
{ > { >     Michael
{ > { >
{ > { > [email-masked] wrote:
{ > { > > The thing is that we discussed dropping quite a lot at/near
{ > { > the ietf
{ > { > > in Philadelphia, and the preferential dropping v reaction
{ > { > times argument.
{ > { > > not that it's impossible to re-visit the decision, but is
there
{ > new
{ > { > > evidence or argument?
{ > { > >
{ > { > > phil
{ > { > >
{ > { > > { -----Original Message-----
{ > { > > { From: Michael Menth
[mailto:[email-masked]]
{ > { > > { Sent: 21 October 2008 17:22
{ > { > > { To: Eardley,PL,Philip,CXR9 R
{ > { > > { Cc: [email-masked]; [email-masked] { Subject:
{ > { > Re: [PCN]
{ > { > > New VersionNotification fordraft-ietf-pcn-baseline- {
{ > { > encoding-01 { {
{ > { > > Hi Phil, { { yes, you are right. My example was ill-conceived.
{ > { > > Currently I cannot { think either of a sensible deployment
{ > { > model that
{ > { > > would not meter all PCN { packets for threshold marking and
all
{ > { > > unmarked PCN packets for excess { marking.
{ > { > > {
{ > { > > { My comment actually concerns the dropping behavior. Its
{ > { > definition
{ > { > > in { the marking draft unnecessarily constrains the use of
{ > { > the meters
{ > { > > and { markers and should be rather defined by deployment
models.
{ > { > > {
{ > { > > { Of course, only sensible freedom should be allowed in the
{ > marking
{ > { > > and { encoding draft. What sensible freedom is depends on
which
{ > { > > deployment { models should be able to be basically
{ > { > supported. Now or
{ > { > > possibly in the { future.
{ > { > > {
{ > { > > { Regards,
{ > { > > {
{ > { > > {     Michael
{ > { > > {
{ > { > > {
{ > { > > { [email-masked] wrote:
{ > { > > { > {
{ > { > > { > { my thinking is what you also suspect at the end of
{ > { > your email:
{ > { > > the { > { description of the packets to be metered and the
{ > { > packets to
{ > { > > be { > re-marked { > { is part of the deployment model and
{ > { > meters and
{ > { > > markers must be { > { configurable with regard to this
respect.
{ > The
{ > { > > same applies to drop { > { preferences. It does not mean
{ > { > that anything
{ > { > > can be done in PCN.
{ > { > > The
{ > { > > { > { restrictions come through the deployment models that
{ > { > say which {
{ > { > > > building { > { blocks MUST be used and how they MUST be
{ > { > configured.
{ > { > > Then, metering { > and { > { marking can be kept general
{ > { > and encoding
{ > { > > does not need to know { > anything { > { about its future use.
{ > { > > { >
{ > { > > { > I disagree with this to some extent.
{ > { > > { >
{ > { > > { > I think that what pkts are metered and what re-marked
{ > { > is something
{ > { > > to be { > standardised in the encoding drafts. This allows
{ > { > each to be
{ > { > > carefully { > thought about and for manufacturers to say that
{ > their
{ > { > > kit is conformant { > with a STD. putting this in a
{ > { > deployment model
{ > { > > is not as good - there { > will (assuming pcn's success)
{ > { > potentially
{ > { > > be many deployment models, and { > many deployment models
{ > { > based on a
{ > { > > particular encoding. The framework is { > that the behaviour
of
{ > the
{ > { > > interior nodes (in terms of both marking { > behaviour &
{ > { > encoding) is
{ > { > > simple and clear, without a whole lot of { > configurable
options.
{ > { > > Meanwhile, there's more freedom in terms of the { >
{ > { > behaviour of the
{ > { > > gateways in how they interpret these marks. Of course { >
{ > { > it may turn
{ > { > > out that in practice there are only a couple of good sets of {
{ > { > > gateway behaviour.
{ > { > > { > Anyway, I read your email as proposing that the marking
and
{ > { > > encoding { > should allow lots of freedom with lots of
{ > configurable
{ > { > > options, and that { > the deployment models should be where
{ > { > things are
{ > { > > standardised in anger.
{ > { > > { > I disagree with that.
{ > { > > { >
{ > { > > {
{ > { > > { --
{ > { > > { 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
{ > { > >
{ > { >
{ > { > --
{ > { > 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
{ > { >
{ > { > _______________________________________________
{ > { > PCN mailing list
{ > { > [email-masked]
{ > { > https://www.ietf.org/mailman/listinfo/pcn
{ > { >
{ > {
{ >
{ 
{ --
{ 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: <[email-masked]>
Date: Wed, 22 Oct 2008 14:18:41 +0100

I think I agree with Phil. We want to have a PCN system which can work
"out of the box" with the minimum configuration necessary. Any
refinements can then be done principally at boundary nodes where most of
the control mechanism will sit.

Toby

> [email-masked]
> Sent: 22 October 2008 13:57
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-
> encoding-01
>

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Oct 2008 15:32:06 +0200

Hi Phil and Toby,

the problem I see is the following.

1) Drop preferences do not have anything to do with marking. What you 
have in mind to standardize is the PCN internal node behavior which is 
part of a deployment model (excess and/or threshold marking based on 
which rates, drop preferences).
2) The nice "out of the box" behavior mentioned by Toby can be achieved 
with a knob "deployment model X" which effects the required settings in 
the router.
3) If preferential dropping of marked packets is the only option for 
dropping behavior for PCN internal nodes, the only indirect measured 
rate termination (IMRT) is possible as flow termination mechanism and 
this is very complex. That's already understood. So, there is not much 
room for further refinement.

Regards,

    Michael

[email-masked] wrote:
>> excess-traffic-rate. Complexity of the boundary nodes is something
>>     
> that
>   
>> { Subject: Re: [PCN] NewVersionNotification
>>     
>> { > { > > carefully { > thought about and for manufacturers to say
>>     
> that
>   
>> { > their
>> { > { > > (+49)-931/888-6632 {
>>

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 15:08:36 +0100

{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ Sent: 22 October 2008 14:32
{ To: Moncaster,T,Toby,CXR9 R; Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN]NewVersionNotification fordraft-ietf-pcn-baseline-
{ encoding-01
{ 
{ Hi Phil and Toby,
{ 
{ the problem I see is the following.
{ 
{ 1) Drop preferences do not have anything to do with marking. What you
{ have in mind to standardize is the PCN internal node behavior which is
{ part of a deployment model (excess and/or threshold marking based on
{ which rates, drop preferences).
No. the meter rates are just parameters. Don't care what the edge
behaviours are. The fact that the excess rate is equal to the
PCN-admissible-rate or PCN-supportable-rate is something quite invisible
to the meter!

{ 2) The nice "out of the box" behavior mentioned by Toby can be
achieved
{ with a knob "deployment model X" which effects the required settings
in
{ the router.
(call it a deployment knob seems to be disguising what you're proposing
- which is to have different PCN-interior-router behaviours, ie
configurable whether it does preferential dropping or not of pkts that
are already excess traffic marked. )

{ 3) If preferential dropping of marked packets is the only option for
{ dropping behavior for PCN internal nodes, the only indirect measured
{ rate termination (IMRT) is possible as flow termination mechanism 

no it isnt. The reaction of speed of marked flow termination is slower
but it still works - and if reaction speed is your most important factor
you wouldn't be using marked flow termination (its benefit is in terms
of not having to make measurements of flow rates).
That was my understanding before, and will read your report on the
plane.

and
{ this is very complex. That's already understood. So, there is not much
{ room for further refinement.
{ 
{ Regards,
{ 
{     Michael
{ 
{ 
{ [email-masked] wrote:
{ > I think I agree with Phil. We want to have a PCN system which can
work
{ > "out of the box" with the minimum configuration necessary. Any
{ > refinements can then be done principally at boundary nodes where
most of
{ > the control mechanism will sit.
{ >
{ > Toby
{ >
{ >
{ >> -----Original Message-----
{ >> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ >> [email-masked]
{ >> Sent: 22 October 2008 13:57
{ >> To: [email-masked]
{ >> Cc: [email-masked]
{ >> Subject: Re: [PCN]NewVersionNotification
fordraft-ietf-pcn-baseline-
{ >> encoding-01
{ >>
{ >> The marking draft at the moment gives very low complexity of
interior
{ >> nodes and their configuration, eg parameters are the threshold-rate
&
{ >> excess-traffic-rate. Complexity of the boundary nodes is something
{ >>
{ > that
{ >
{ >> we understand less well. I see the deployment model as being about
the
{ >> boundary node behaviour, where it's appropriate to have a bit of
{ >> freedom
{ >> in terms of >1 different (EXP) behaviours.
{ >> { -----Original Message-----
{ >> { From: Michael Menth [mailto:[email-masked]]
{ >> { Sent: 22 October 2008 10:13
{ >> { To: Eardley,PL,Philip,CXR9 R
{ >> { Cc: [email-masked]; [email-masked]
{ >> { Subject: Re: [PCN] NewVersionNotification
{ >>
{ > fordraft-ietf-pcn-baseline-
{ >
{ >> { encoding-01
{ >> {
{ >> { Hi Phil,
{ >> {
{ >> { I agree with you that the number of standardized deployment
models
{ >> { should be kept to a minimum and to simplify deployment. However,
the
{ >> { complexity of configuration, standardization, and operation
rather
{ >> { depends on the complexity of the deployment model itself and
there
{ >> are
{ >> { large differences. I don't believe that this issue has been
{ >> understood
{ >> { very well so far.
{ >> {
{ >> { Regards,
{ >> {
{ >> {     Michael
{ >> {
{ >> { [email-masked] wrote:
{ >> { > Remember that such choice adds complexity to the router, the
{ >> { > standardisation and the operation.
{ >> { >
{ >> { > { -----Original Message-----
{ >> { > { From: Georgios Karagiannis [mailto:[email-masked]]
{ >> { > { Sent: 22 October 2008 09:55
{ >> { > { To: [email-masked]; Eardley,PL,Philip,CXR9
R
{ >> { > { Cc: [email-masked]
{ >> { > { Subject: RE: [PCN] NewVersionNotification
{ >> fordraft-ietf-pcn-baseline-
{ >> { > { encoding-01
{ >> { > {
{ >> { > { Hi all
{ >> { > {
{ >> { > { I agree with Michael that such constraints are better
suitable
{ >> for
{ >> { > { deployment models.
{ >> { > {
{ >> { > { Best regards,
{ >> { > { Georgios
{ >> { > {
{ >> { > {
{ >> { > { > -----Original Message-----
{ >> { > { > From: [email-masked] [mailto:[email-masked]] On
{ >> { > { > Behalf Of Michael Menth
{ >> { > { > Sent: woensdag 22 oktober 2008 10:37
{ >> { > { > To: [email-masked]
{ >> { > { > Cc: [email-masked]
{ >> { > { > Subject: Re: [PCN] NewVersionNotification
{ >> { > { > fordraft-ietf-pcn-baseline-encoding-01
{ >> { > { >
{ >> { > { > Hi Phil,
{ >> { > { >
{ >> { > { > the issue is whether the marking draft should also restrict
{ >> { > { > drop preferences. Dropping of marked packets is not needed
{ >> { > { > from a general marking perspective. It's only needed for
{ >> { > { > indirect measured rate termination which is only one
{ >> { > { > termination option out of many others.
{ >> { > { > Requiring preferential dropping of special packets only
{ >> { > { > limits the number of options of what you can do with PCN
{ >> { > { > marking. Therefore, such constraints are better suitable
for
{ >> { > { > deployment models.
{ >> { > { >
{ >> { > { > Regards,
{ >> { > { >
{ >> { > { >     Michael
{ >> { > { >
{ >> { > { > [email-masked] wrote:
{ >> { > { > > The thing is that we discussed dropping quite a lot
at/near
{ >> { > { > the ietf
{ >> { > { > > in Philadelphia, and the preferential dropping v reaction
{ >> { > { > times argument.
{ >> { > { > > not that it's impossible to re-visit the decision, but is
{ >> there
{ >> { > new
{ >> { > { > > evidence or argument?
{ >> { > { > >
{ >> { > { > > phil
{ >> { > { > >
{ >> { > { > > { -----Original Message-----
{ >> { > { > > { From: Michael Menth
{ >> [mailto:[email-masked]]
{ >> { > { > > { Sent: 21 October 2008 17:22
{ >> { > { > > { To: Eardley,PL,Philip,CXR9 R
{ >> { > { > > { Cc: [email-masked]; [email-masked] {
Subject:
{ >> { > { > Re: [PCN]
{ >> { > { > > New VersionNotification fordraft-ietf-pcn-baseline- {
{ >> { > { > encoding-01 { {
{ >> { > { > > Hi Phil, { { yes, you are right. My example was ill-
{ >> conceived.
{ >> { > { > > Currently I cannot { think either of a sensible
deployment
{ >> { > { > model that
{ >> { > { > > would not meter all PCN { packets for threshold marking
and
{ >> all
{ >> { > { > > unmarked PCN packets for excess { marking.
{ >> { > { > > {
{ >> { > { > > { My comment actually concerns the dropping behavior. Its
{ >> { > { > definition
{ >> { > { > > in { the marking draft unnecessarily constrains the use
of
{ >> { > { > the meters
{ >> { > { > > and { markers and should be rather defined by deployment
{ >> models.
{ >> { > { > > {
{ >> { > { > > { Of course, only sensible freedom should be allowed in
the
{ >> { > marking
{ >> { > { > > and { encoding draft. What sensible freedom is depends on
{ >> which
{ >> { > { > > deployment { models should be able to be basically
{ >> { > { > supported. Now or
{ >> { > { > > possibly in the { future.
{ >> { > { > > {
{ >> { > { > > { Regards,
{ >> { > { > > {
{ >> { > { > > {     Michael
{ >> { > { > > {
{ >> { > { > > {
{ >> { > { > > { [email-masked] wrote:
{ >> { > { > > { > {
{ >> { > { > > { > { my thinking is what you also suspect at the end of
{ >> { > { > your email:
{ >> { > { > > the { > { description of the packets to be metered and
the
{ >> { > { > packets to
{ >> { > { > > be { > re-marked { > { is part of the deployment model
and
{ >> { > { > meters and
{ >> { > { > > markers must be { > { configurable with regard to this
{ >> respect.
{ >> { > The
{ >> { > { > > same applies to drop { > { preferences. It does not mean
{ >> { > { > that anything
{ >> { > { > > can be done in PCN.
{ >> { > { > > The
{ >> { > { > > { > { restrictions come through the deployment models
that
{ >> { > { > say which {
{ >> { > { > > > building { > { blocks MUST be used and how they MUST be
{ >> { > { > configured.
{ >> { > { > > Then, metering { > and { > { marking can be kept general
{ >> { > { > and encoding
{ >> { > { > > does not need to know { > anything { > { about its future
{ >> use.
{ >> { > { > > { >
{ >> { > { > > { > I disagree with this to some extent.
{ >> { > { > > { >
{ >> { > { > > { > I think that what pkts are metered and what re-marked
{ >> { > { > is something
{ >> { > { > > to be { > standardised in the encoding drafts. This
allows
{ >> { > { > each to be
{ >> { > { > > carefully { > thought about and for manufacturers to say
{ >>
{ > that
{ >
{ >> { > their
{ >> { > { > > kit is conformant { > with a STD. putting this in a
{ >> { > { > deployment model
{ >> { > { > > is not as good - there { > will (assuming pcn's success)
{ >> { > { > potentially
{ >> { > { > > be many deployment models, and { > many deployment models
{ >> { > { > based on a
{ >> { > { > > particular encoding. The framework is { > that the
behaviour
{ >> of
{ >> { > the
{ >> { > { > > interior nodes (in terms of both marking { > behaviour &
{ >> { > { > encoding) is
{ >> { > { > > simple and clear, without a whole lot of { > configurable
{ >> options.
{ >> { > { > > Meanwhile, there's more freedom in terms of the { >
{ >> { > { > behaviour of the
{ >> { > { > > gateways in how they interpret these marks. Of course { >
{ >> { > { > it may turn
{ >> { > { > > out that in practice there are only a couple of good sets
of
{ >> {
{ >>
{ >> { > { > > gateway behaviour.
{ >> { > { > > { > Anyway, I read your email as proposing that the
marking
{ >> and
{ >> { > { > > encoding { > should allow lots of freedom with lots of
{ >> { > configurable
{ >> { > { > > options, and that { > the deployment models should be
where
{ >> { > { > things are
{ >> { > { > > standardised in anger.
{ >> { > { > > { > I disagree with that.
{ >> { > { > > { >
{ >> { > { > > {
{ >> { > { > > { --
{ >> { > { > > { 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
{ >> { > { > >
{ >> { > { >
{ >> { > { > --
{ >> { > { > 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
{ >> { > { >
{ >> { > { > _______________________________________________
{ >> { > { > PCN mailing list
{ >> { > { > [email-masked]
{ >> { > { > https://www.ietf.org/mailman/listinfo/pcn
{ >> { > { >
{ >> { > {
{ >> { >
{ >> {
{ >> { --
{ >> { 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
{ >>
{ >> _______________________________________________
{ >> PCN mailing list
{ >> [email-masked]
{ >> https://www.ietf.org/mailman/listinfo/pcn
{ >>
{ 
{ --
{ 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