Subject: RE: [PCN] charter text update

From: <[email-masked]>
Date: Thu, 1 Feb 2007 12:26:20 -0000

A mixture of significant comments and suggested minor re-phrasings.
Best wishes
phil

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]
> Sent: 25 January 2007 07:23
> To: [email-masked]
> Subject: [PCN] charter text update
> 
> (I thought I had sent this several days ago, but it apparently never
> made it to the list?)
> 
> Hi,
> 
> below is a modified version of the PCN charter posted to this list a
> while ago. I believe it reflects the consensus after the face-to-face
> and mailing list discussions in and after Montreal.
> 
> Compared to the earlier version, the major changes are:
> 
> 	- removal of SIP, application-based and PW deployment scenarios
> 	- stronger language on assumptions and scope
> 	- refactored deliverables and milestones
> 	- name change (don't feel strongly about this)
> 
> Please send your comments to the list.
> 
> Lars
> 
>
------------------------------------------------------------------------
> --
> 
> Flow Admission and Preemption (flap)
> Chair(s):
>     tbd
> 
> 
> Description of Working Group:
> 
> The Flow Admission and Preemption (FLAP) working group develops flow
> admission and flow preemption mechanisms for deployment along the
> edge of a network domain that protect the quality-of-service that
> previously-admitted flows experience within the domain during times
> of congestion. These mechanisms act on aggregated congestion and pre-
> congestion signals from routers within the network domain and control
> the admission of new flows into the domain or preempt previously-
> admitted flows. Although designed to work together, flow admission
> and flow preemption are independent mechanisms, and the use of one
> does not require the use of the other.

In the above para I think "region" would be better than "domain"

I think you're already planning to change "signals" to "information".

> 
> The FLAP WG will specify the following components of an integrated
> flow admission and preemption mechanism:

I don't like "integrated". Suggest deleting "of an integrated flow
admission and preemption mechanism"

> 
>     (1) a general architecture for flow admission and preemption based
>         on aggregated (pre-)congestion signals
> 
>     (2) conditions under which interior routers generate
>         (pre-)congestion signals
> 
>     (3) encoding and transport of (pre-)congestion signals
>         to the appropriate ingress routers of the network domain

I think you're already planning to change (3). I wonder if it's worth
splitting in two
(3a) encoding of (pre-)congestion information
(3b) transport of (pre-)congestion information to the appropriate
ingress routers of the network domain
I assume in (3b) you're referring to the transport of info from the
PCN-region's egress to ingress routers (eg of the
congestion-level-estimate, in the language of the CL-drafts). When it's
combined in the same bullet as (3a) you could read it as the transport
from the router within the PCN-region to the egress router (which is
just IP)

> 
>     (4) edge router control mechanisms for flow admission and
>         preemption based on aggregated (pre-)congestion information

I believe "(pre-)congestion" means "pre-congestion &/or congestion".
Bringing "congestion" in scope is I think a big change compared to what
we talked about at the BoF. At least I'm worried that we've had no
discussion about it yet. I guess I'm uncomfortable about adding it, at
least unless it's a bit clearer how wide we're looking. Is consideration
of congestion marking and encoding really in scope? (ie items (2) &
(3a)). Or are we just trying to allow something like the following: when
calculating the amount of excess traffic, as well as counted the
prmpt-marked pkts also take into account the congestion marked pkts. 
Sorry if I've read far too much into a pair of brackets!

> 
> The WG focuses on the overall architecture and specifically the
> signaling interfaces needed to realize it. Standards-track protocols
> are only developed when necessary for interoperability. When
> algorithms are not necessary for interoperability the WG may document
> examples or provide recommended solutions, however such work should
> not be done at the expense of normative specifications.

One of the 'open issues' at the BoF was what level of detail the WG
should specify. For instance (quoting slide 18):
Implementation? ("must use virtual queue") <=No!
Algorithm? ("use this formula")
Behaviour? ("produce this behaviour measured externally", as in
DiffServ)

Behaviour is good with me (if I understand it correctly - the external
behaviour would have to match some formula when measured, but don't care
about the internal details to produce it).

> 
> 
> The initial scope of the FLAP WG is restricted in the following ways:

suggest replacing "in the following ways" with "by making the following
assumptions" and in (A) replace "develop these components for" by "these
components are deployed in". (Note, this suggestion isn't supposed to
change meaning, just English suggestion.)

> 
>     (A) develop these components for a single DiffServ region,
>         where all edge and interior routers are FLAP-enabled
>         and mutually trust each other
> 
>     (B) all flows handled by these mechanisms are inelastic and
>         constrained to a known maximum rate through policing or
shaping
> 
>     (C) the number of flows across any potential aggregation
bottleneck
>         is sufficiently large for stateless, statistical mechanisms
> to be
>         effective
> 
>     (D) aggregation occurs either on links or ingress/egress pairs;
>         mechanisms must further define relevant limits

I think (C) is enough and (D) is not needed. 

> 
>     (E) flows may have different precedence, but the applicability
>         of these mechanisms for emergency use (911, GETS, WPS, MLPP,
> etc.)
>         is out of scope

given the discussion with ken, I wonder if something like this would be
better?
(E) assuming that all flows are allowed to be pre-empted. Note that
legal/regulatory reasons may prevent pre-emption of some flows in
practice (eg emergency, PSTN), but such considerations are out of scope.

> 
> After completion of the initial phase, the FLAP WG may recharter to
> develop solutions for scenarios where some of these restrictions are
> not in place. It may also recharter to consider applying the FLAP
> mechanisms to additional deployment scenarios (operation over
> concatenated DiffServ regions, FLAP-aware application mechanisms,
> etc.). The WG may also consider to investigate additional response
> mechanisms that act on (pre-)congestion signals. One example could be
> flow-rate adaptation (rather than flow admission/preemption) during
> times of congestion. The details of these work items are outside the
> scope of the initial phase; but the WG may want to consider their 
> requirements during the design of the initial components.

Ok. Except in the BoF there was consensus to keep the following future
case strongly in mind even during the initial charter, by adding the
following to the charter:
[anna email 17nov06] "In particular, after re-chartering it's expected
that the WG will cover the case with multiple, non-trusting domains.
However, even during the initial standardization phase, this case needs
to be kept in mind, as the anti-cheating solution will have impact on
e.g. the choice of encoding."
Should something on these lines be in the charter?

> 
> However in the initial scope this mechanism is out-of-scope with the
> exception that the developed solution should not, if possible,
> prevent a future evolution to support this.

replace "this mechanism is" by "these scenarios are" and "support this"
by "support them"
> 
> 
> Goals and Milestones:
> 
> Jul 2007   Flow Admission and Preemption Architecture
>             (Informational)
> 
> Jul 2007   Survey of Encoding and Transport Choices of
>             (Pre-)Congestion Signals within a DiffServ Region
>             (Informational)
> 
> Nov 2007   Flow Admission and Preemption within a DiffServ
>             Region (Informational)
> 
> Nov 2007   (Pre-)Congestion Detection within a DiffServ Region
>             (Proposed Standard)
> 
> Mar 2008   Encoding and Transport of (Pre-)Congestion Signals
>             within a DiffServ Region to Flow Egress (Proposed
Standard)
> 
> Mar 2008   Transport from Flow Egress in a DiffServ Region of
> information
>             (possibly aggregated) or Admission/Preemption Signals to
>             DiffServ edge devices. (Proposed Standard)

in items 2, 5 & 6 I assume "transport" refers to the extension to eg
RSVP to carry the congestion-level-estimate info from egress to ingress?
In item 6, I think this is too vague. Obvious possible transports are
rsvp, nsis and sip. Rsvp extensions could be done in PCN WG or in TSVWG
but nsis & sip extensions would presumably be done in their WGs. 
I think the WG could
- do rsvp extensions
- &/or do a generic analysis of signalling extensions required (ie a doc
designed to feed detailed requirements & approach to other WGs that
would do the specific protocol extensions).

In item 2, I think mention of transport could be deleted (what would the
survey of transport choices cover?)
In item 5, I think mention of transport could be deleted (not really
issue related to encoding)
Item 6, tweak wording as eg rsvp extension for ingress-to-egress as well
as egress-to-ingress (currently former is in item 5 & latter in item 6,
but would be easier to do them together)

> 
> Mar 2008   Suggested Flow Admission and Preemption Edge Mechanisms
>             (Informational)
>
I think this probably needs to be Standards track. Especially when the
PCN-region spans multiple domains. Otherwise somehow the edges would
have to negotiate with each other to discover what mechanism a
particular ingress was using and hence what sort of info this egress
should send to it. So for ease of interoperability one normative scheme
would be best.

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Feb 2007 15:04:08 +0200

>> admission and flow preemption mechanisms for deployment along the
...
> In the above para I think "region" would be better than "domain"

Domain is actually the correct term. A region is a "set of contiguous  
DS domains" according to RFC2475, which I have brought the latest  
charter (separate email) in line with.

> I think you're already planning to change "signals" to "information".

Yup.

> admission and preemption mechanism"

Meanwhile changed to:

The PCN WG will specify the following components to protect the  
quality-of-service of flows within a DiffServ domain

> from the router within the PCN-region to the egress router (which is

The milestones had already split this differently, namely:

Mar 2008   Encoding and Transport of (Pre-)Congestion Information
            from within a DiffServ Domain to the Egress
            (Proposed Standard)

Mar 2008   Encoding and Transport of (Pre-)Congestion Information
	   from the Domain Egress to the Ingress
	   (Proposed Standard)

I'm fine with making the same split here. Or do you think that  
factoring out the marking into a third item, with the other two being  
only about the transport then, would be better?

> Sorry if I've read far too much into a pair of brackets!

The reason for changing this was that a domain can go from  
equilibrium to full-blown congestion without being in a pre- 
congestion phase, for example, due to equipment failure. If PCN was  
only acting on pre-congestion information, would it be able to handle  
this case? (I might miss something here.)

> about the internal details to produce it).

I sort of assumed behavior. Any idea for an appropriate phrasing?

> practice (eg emergency, PSTN), but such considerations are out of  

Not sure. Ken?

> Should something on these lines be in the charter?

The last sentence of that paragraph means to say that, but maybe  
isn't strong enough for your liking?

> replace "this mechanism is" by "these scenarios are" and "support  

I just removed this sentence.

> RSVP to carry the congestion-level-estimate info from egress to  

Yes. And from interior router to egress.

> In item 6, I think this is too vague.

Items 5&6 now read:

Mar 2008   Encoding and Transport of (Pre-)Congestion Information
            from within a DiffServ Domain to the Egress
            (Proposed Standard)

Mar 2008   Encoding and Transport of (Pre-)Congestion Information
	   from the Domain Egress to the Ingress
	   (Proposed Standard)

> Obvious possible transports are

Interaction with other WGs is actually an important thing missing  
from the charter that I will add.

> survey of transport choices cover?)

How to get the information from the marker to the egress, and then to  
the ingress.

> issue related to encoding)

With some encoding schemes, the transport is implicit (e.g., using an  
IP header bit). For others (NSIS, RSVP), something more needs to be  
said.

> but would be easier to do them together)

I'm not sure if I want to limit this to an RSVP extension in the  
charter text already. The idea is that item 2 would provide guidance  
to the WG on what to chose for items 5 and 6.

> should send to it. So for ease of interoperability one normative  

We've gone back and forth on this. I was of the same opinion  
originally, but several people have stated that it wouldn't need to  
be PS. But I think this isn't critical for now: If the WG decides  
that it needs to be PS for interoperability, it can be changed later.

Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 1 Feb 2007 14:30:52 +0100

Phil,

your suggestions are good. Some questions, remarks and personal points
of view:

- we should clarify whether "congestion" means packet losses,
pre-emption 
  marking or just a different interpretation of the rate packets marked 
  as "pre-congested" (assuming a single pre-congestion mark for 
  admission control and pre-emption decision and a rate threshold to 
  decide on the interpretation).
  I think we should deal with packets marked by a PCN mechanism only and

  adapt our terminology (I've used "congestion" too, I admit).

- (D) which you suggest to be deleted refers to ingress/egress
aggregation. 
  The ingress/egress traffic evaluation by the egress gateway is
important. 
  I just wanted to mention, but I don't have a strong view whether that 
  should be mentioned by the charter.

- your proposal to reword (E) may re-open the pre-emprtion debate.
  The prior text seems to say that PCN delivers a 
  pre-emption trigger but doesn't demand interpretation. Your proposed 
  text seems to say the pre-emption is active and it's out of scope of 
  PCN to worry about deactivation. 
  If I understood that right, I prefer the original text.

- I agree that "transport of admission/preemption information" should 
  be clarified the way you propose.

- Trusted DiffServ region is allright with me to. If you can't trust 
  another domain, then the region is just your own domain.

I agree to all of your proposals which I didn't comment here.

Regards,

Ruediger

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]]
|Sent: Thursday, February 01, 2007 1:26 PM
|To: [email-masked]; [email-masked]
|Subject: RE: [PCN] charter text update
|
|
|A mixture of significant comments and suggested minor re-phrasings.
|Best wishes
|phil
|
|> -----Original Message-----
|> From: Lars Eggert [mailto:[email-masked]]
|> Sent: 25 January 2007 07:23
|> To: [email-masked]
|> Subject: [PCN] charter text update
|> 
|> (I thought I had sent this several days ago, but it apparently never
|> made it to the list?)
|> 
|> Hi,
|> 
|> below is a modified version of the PCN charter posted to this list a
|> while ago. I believe it reflects the consensus after the face-to-face
|> and mailing list discussions in and after Montreal.
|> 
|> Compared to the earlier version, the major changes are:
|> 
|> 	- removal of SIP, application-based and PW deployment scenarios
|> 	- stronger language on assumptions and scope
|> 	- refactored deliverables and milestones
|> 	- name change (don't feel strongly about this)
|> 
|> Please send your comments to the list.
|> 
|> Lars
|> 
|>
|---------------------------------------------------------------
|---------
|> --
|> 
|> Flow Admission and Preemption (flap)
|> Chair(s):
|>     tbd
|> 
|> 
|> Description of Working Group:
|> 
|> The Flow Admission and Preemption (FLAP) working group develops flow
|> admission and flow preemption mechanisms for deployment along the
|> edge of a network domain that protect the quality-of-service that
|> previously-admitted flows experience within the domain during times
|> of congestion. These mechanisms act on aggregated congestion and pre-
|> congestion signals from routers within the network domain and control
|> the admission of new flows into the domain or preempt previously-
|> admitted flows. Although designed to work together, flow admission
|> and flow preemption are independent mechanisms, and the use of one
|> does not require the use of the other.
|
|In the above para I think "region" would be better than "domain"
|
|I think you're already planning to change "signals" to "information".
|
|> 
|> The FLAP WG will specify the following components of an integrated
|> flow admission and preemption mechanism:
|
|I don't like "integrated". Suggest deleting "of an integrated flow
|admission and preemption mechanism"
|
|> 
|>     (1) a general architecture for flow admission and 
|preemption based
|>         on aggregated (pre-)congestion signals
|> 
|>     (2) conditions under which interior routers generate
|>         (pre-)congestion signals
|> 
|>     (3) encoding and transport of (pre-)congestion signals
|>         to the appropriate ingress routers of the network domain
|
|I think you're already planning to change (3). I wonder if it's worth
|splitting in two
|(3a) encoding of (pre-)congestion information
|(3b) transport of (pre-)congestion information to the appropriate
|ingress routers of the network domain
|I assume in (3b) you're referring to the transport of info from the
|PCN-region's egress to ingress routers (eg of the
|congestion-level-estimate, in the language of the CL-drafts). When it's
|combined in the same bullet as (3a) you could read it as the transport
|from the router within the PCN-region to the egress router (which is
|just IP)
|
|> 
|>     (4) edge router control mechanisms for flow admission and
|>         preemption based on aggregated (pre-)congestion information
|
|I believe "(pre-)congestion" means "pre-congestion &/or congestion".
|Bringing "congestion" in scope is I think a big change compared to what
|we talked about at the BoF. At least I'm worried that we've had no
|discussion about it yet. I guess I'm uncomfortable about adding it, at
|least unless it's a bit clearer how wide we're looking. Is 
|consideration
|of congestion marking and encoding really in scope? (ie items (2) &
|(3a)). Or are we just trying to allow something like the 
|following: when
|calculating the amount of excess traffic, as well as counted the
|prmpt-marked pkts also take into account the congestion marked pkts. 
|Sorry if I've read far too much into a pair of brackets!
|
|> 
|> The WG focuses on the overall architecture and specifically the
|> signaling interfaces needed to realize it. Standards-track protocols
|> are only developed when necessary for interoperability. When
|> algorithms are not necessary for interoperability the WG may document
|> examples or provide recommended solutions, however such work should
|> not be done at the expense of normative specifications.
|
|One of the 'open issues' at the BoF was what level of detail the WG
|should specify. For instance (quoting slide 18):
|Implementation? ("must use virtual queue") <=No!
|Algorithm? ("use this formula")
|Behaviour? ("produce this behaviour measured externally", as in
|DiffServ)
|
|Behaviour is good with me (if I understand it correctly - the external
|behaviour would have to match some formula when measured, but 
|don't care
|about the internal details to produce it).
|
|> 
|> 
|> The initial scope of the FLAP WG is restricted in the following ways:
|
|suggest replacing "in the following ways" with "by making the following
|assumptions" and in (A) replace "develop these components for" 
|by "these
|components are deployed in". (Note, this suggestion isn't supposed to
|change meaning, just English suggestion.)
|
|> 
|>     (A) develop these components for a single DiffServ region,
|>         where all edge and interior routers are FLAP-enabled
|>         and mutually trust each other
|> 
|>     (B) all flows handled by these mechanisms are inelastic and
|>         constrained to a known maximum rate through policing or
|shaping
|> 
|>     (C) the number of flows across any potential aggregation
|bottleneck
|>         is sufficiently large for stateless, statistical mechanisms
|> to be
|>         effective
|> 
|>     (D) aggregation occurs either on links or ingress/egress pairs;
|>         mechanisms must further define relevant limits
|
|I think (C) is enough and (D) is not needed. 
|
|> 
|>     (E) flows may have different precedence, but the applicability
|>         of these mechanisms for emergency use (911, GETS, WPS, MLPP,
|> etc.)
|>         is out of scope
|
|given the discussion with ken, I wonder if something like this would be
|better?
|(E) assuming that all flows are allowed to be pre-empted. Note that
|legal/regulatory reasons may prevent pre-emption of some flows in
|practice (eg emergency, PSTN), but such considerations are out 
|of scope.
|
|
|> 
|> After completion of the initial phase, the FLAP WG may recharter to
|> develop solutions for scenarios where some of these restrictions are
|> not in place. It may also recharter to consider applying the FLAP
|> mechanisms to additional deployment scenarios (operation over
|> concatenated DiffServ regions, FLAP-aware application mechanisms,
|> etc.). The WG may also consider to investigate additional response
|> mechanisms that act on (pre-)congestion signals. One example could be
|> flow-rate adaptation (rather than flow admission/preemption) during
|> times of congestion. The details of these work items are outside the
|> scope of the initial phase; but the WG may want to consider their 
|> requirements during the design of the initial components.
|
|Ok. Except in the BoF there was consensus to keep the following future
|case strongly in mind even during the initial charter, by adding the
|following to the charter:
|[anna email 17nov06] "In particular, after re-chartering it's expected
|that the WG will cover the case with multiple, non-trusting domains.
|However, even during the initial standardization phase, this case needs
|to be kept in mind, as the anti-cheating solution will have impact on
|e.g. the choice of encoding."
|Should something on these lines be in the charter?
|
|> 
|> However in the initial scope this mechanism is out-of-scope with the
|> exception that the developed solution should not, if possible,
|> prevent a future evolution to support this.
|
|replace "this mechanism is" by "these scenarios are" and "support this"
|by "support them"
|> 
|> 
|> Goals and Milestones:
|> 
|> Jul 2007   Flow Admission and Preemption Architecture
|>             (Informational)
|> 
|> Jul 2007   Survey of Encoding and Transport Choices of
|>             (Pre-)Congestion Signals within a DiffServ Region
|>             (Informational)
|> 
|> Nov 2007   Flow Admission and Preemption within a DiffServ
|>             Region (Informational)
|> 
|> Nov 2007   (Pre-)Congestion Detection within a DiffServ Region
|>             (Proposed Standard)
|> 
|> Mar 2008   Encoding and Transport of (Pre-)Congestion Signals
|>             within a DiffServ Region to Flow Egress (Proposed
|Standard)
|> 
|> Mar 2008   Transport from Flow Egress in a DiffServ Region of
|> information
|>             (possibly aggregated) or Admission/Preemption Signals to
|>             DiffServ edge devices. (Proposed Standard)
|
|in items 2, 5 & 6 I assume "transport" refers to the extension to eg
|RSVP to carry the congestion-level-estimate info from egress 
|to ingress?
|In item 6, I think this is too vague. Obvious possible transports are
|rsvp, nsis and sip. Rsvp extensions could be done in PCN WG or in TSVWG
|but nsis & sip extensions would presumably be done in their WGs. 
|I think the WG could
|- do rsvp extensions
|- &/or do a generic analysis of signalling extensions required 
|(ie a doc
|designed to feed detailed requirements & approach to other WGs that
|would do the specific protocol extensions).
|
|In item 2, I think mention of transport could be deleted (what 
|would the
|survey of transport choices cover?)
|In item 5, I think mention of transport could be deleted (not really
|issue related to encoding)
|Item 6, tweak wording as eg rsvp extension for 
|ingress-to-egress as well
|as egress-to-ingress (currently former is in item 5 & latter in item 6,
|but would be easier to do them together)
|
|> 
|> Mar 2008   Suggested Flow Admission and Preemption Edge Mechanisms
|>             (Informational)
|>
|I think this probably needs to be Standards track. Especially when the
|PCN-region spans multiple domains. Otherwise somehow the edges would
|have to negotiate with each other to discover what mechanism a
|particular ingress was using and hence what sort of info this egress
|should send to it. So for ease of interoperability one normative scheme
|would be best.
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: ken carlberg <[email-masked]>
Date: Thu, 1 Feb 2007 08:40:47 -0500

>> practice (eg emergency, PSTN), but such considerations are out of  

the original was fine by me, and i think the proposed change loses  
part of the point that was being in the original.  And I'm kind of in  
agreement with what Ruediger just stated.  However, if something   
needs to be stated about pre-emption, perhaps something like this may  
help.

(F) deployment of pre-emption as a (re)action may be subject to legal/ 
regulatory conditions.  But such conditions are out of scope.

-ken

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 1 Feb 2007 14:44:45 +0100

Leaving (E) like suggested by Lars and adding (F) is allright with me
too.

Regards, Ruediger

|-----Original Message-----
|From: ken carlberg [mailto:[email-masked]]
|Sent: Thursday, February 01, 2007 2:41 PM
|To: Lars Eggert
|Cc: [email-masked]
|Subject: Re: [PCN] charter text update
|
|
|>>>     (E) flows may have different precedence, but the applicability
|>>>         of these mechanisms for emergency use (911, GETS, 
|WPS, MLPP,
|>>> etc.)
|>>>         is out of scope
|>>
|>> given the discussion with ken, I wonder if something like this  
|>> would be
|>> better?
|>> (E) assuming that all flows are allowed to be pre-empted. Note that
|>> legal/regulatory reasons may prevent pre-emption of some flows in
|>> practice (eg emergency, PSTN), but such considerations are out of  
|>> scope.
|>
|> Not sure. Ken?
|
|the original was fine by me, and i think the proposed change loses  
|part of the point that was being in the original.  And I'm kind of in  
|agreement with what Ruediger just stated.  However, if something   
|needs to be stated about pre-emption, perhaps something like this may  
|help.
|
|(F) deployment of pre-emption as a (re)action may be subject to legal/ 
|regulatory conditions.  But such conditions are out of scope.
|
|-ken
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|