RE: [PCN] PCN updated charter

["Jozef Babiarz" <[e-mail]>]

What Hannes is suggesting makes sense. The schedule is too aggressive
and it would not allow time for WG to discuss and analyze the different
proposals. I would like to suggest that the deliverables be moved out by
one or two meetings. 

Hannes asked:
">> Nov 2007          initial signaling analysis Internet Draft

Why cannot the work on this draft started earlier? Is there a dependency

on another draft?"

[joe]Signalling analysis can start anytime, however, it can not be
finished until router marking behavior, flow admission control and
pre-emption
mechanisms are agreed to.

Regards, Joe

Telephone: [phone] 
Email: [e-mail]
-----Original Message-----
From: Hannes Tschofenig [mailto:[e-mail]] 
Sent: Friday, November 24, 2006 1:43 PM
To: Anna Charny (acharny)
Cc: [e-mail]
Subject: Re: [PCN] PCN updated charter

Hi Anna,

sorry for not being specific in my previous mail. Note that it depends 
on your opinion about milestones, but I think they should somehow 
reflect that is being done in the working group. It gives the outside 
world the impression that the IETF is always too slow with their work if

the group does not hit milestones. After some experience with IETF work 
I tend to be a bit more realistic of how long it takes to produce sound 
documents; no matter who is author of the document or how simple the 
subject is (or seems to be).



 >> Nov 2006          initial problem statement Internet Draft
 >> Nov 2006          initial deployment models Internet Drafts

These two documents can only refer to the submission of the individual 
submissions once the working group is chartered, I guess.

It is not realistic to assume that the WG will be chartered by November 
2006.

 >> March 2007        initial router marking behavior (including
encoding)
 >> Internet Drafts
 >> March 2007        initial flow admission control and pre-emption
 >> mechanisms Internet Drafts
 >>                   (including edge node measurements)
 >> March 2007        initial applicability statement Internet Draft

Do you think you can accomplish some work within the next two months to 
have
* all these individual submissions ready by
"
February 26, Monday - Internet Draft Cut-off for initial document (-00) 
submission by 09:00 ET (14:00 UTC/GMT)
"
?

Or do these documents even refer to the initial version of working group

documents? If yes, then this pretty much impossible to accomplish.
You might want to differentiate these two cases since charters typically

refer to working group documents rather than some arbitrary docs that 
have been sent to the working group.


 >> March/July 2007   submit Problem statement to IESG for approval as
 >> informational RFC

Decide whether you want the milestone to be March or July.

If it is March and let us assume that the working group is created early

December then you need to have an individual submission turned into a 
working group document. You need to confirm this decision on the mailing

list and that takes about two weeks. Since you have XMAS breaks you will

have the working group document sometime late in Dec. / beginning of 
Jan. since only the document authors (and their co-workers) will be 
excited about the idea of making them a working group item (everyone 
else in on holiday). Then, you need to work on the document. You need 
reviews, draft updates since you cannot assume that the first version is

already ready for IESG. Now, if the submission deadline is March 5 you 
need to start a  working group last call early February since that takes

at best 2 weeks. Then, give the authors about 2 weeks to update the 
document in such a way that it does not require another review cycle and

to get it ready for the submission deadline.


 >> July 2007         submit deployment models to IESG for approval as
 >> informational RFC
 >> July 2007         submit applicability statement to IESG for
approval
 > as
 >> informational RFC
 >>                   (may be part of the deployment models)
 >> July 2007         initial manageability issues document Internet
Draft

I also think that these milestones are far too optimistic. They just 
seem to assume that everything just works great with every document and 
nobody raises issues that require some level of discussions.

 >> Nov 2007          submit router marking behavior to IESG for
approval
 > as
 >> standards track RFC
 >> Nov 2007/Mar 2008 submit flow admission control and pre-emption
 >> mechanism as standard track RFC

Hard to tell whether these documents will be completed by this time. 
Could be possible.

 >> Nov 2007          initial signaling analysis Internet Draft

Why cannot the work on this draft started earlier? Is there a dependency

on another draft?

 >> Nov 2007          submit manageability issues document to IESG for
 >> approval as informational RFC
 >> Mar 2008          re-charter or close

Does this make sense to you?

Ciao
Hannes

Anna Charny (acharny) wrote:
> Hi Hannes,
> 
> Thanks for your feedback. Do you have specific suggestions on how to
> change the milestones?  What specifically makes you think the current
> ones are not realistic?
> 
> Thanks,
> Anna  
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]] 
> Sent: Friday, November 24, 2006 11:45 AM
> To: Anna Charny (acharny)
> Cc: [e-mail]
> Subject: Re: [PCN] PCN updated charter
> 
> Hi Anna,
> 
> obviously the milestones are not realistic.
> 
> Ciao
> Hannes
> 
> Anna Charny (acharny) wrote:
>> Dear all,
>>  
>> The proposed PCN charter has been updated based on the (very few) 
>> recent comments we received.
>> The new version has been uploaded, and is also attached at the end of

>> this email for convenience.
>>
>> The only difference from the previously posted version is a wording 
>> change below:
>>
>> 2.
>>   ....
>>   (b) Application-controlled Admission and Pre-emption: routers
within
>>         the DiffServ region are PCN-capable and trusted e.g. SIP 
>> endpoints
>>         (gateway or host) perform admission and flow pre-emption
>>  
>> TO:
>> 2.
>>   .....
>>   (b)  Application-controlled Admission and Pre-emption: routers
> within
>>        the DiffServ region are PCN-capable and trusted 
>> application-controlled
>>        (e.g., SIP) endpoints (gateway or host) based on the marking, 
>> perform
>>        admission and flow pre-emption.
>>
>> If you had sent us any email with proposed changes that was 
>> inadvertently missed and not reflected, please let us know right
away.
>>  
>>  
>> Best Regards,
>> Anna and Scott
>> PCN BOF Co-Chairs
>>
>> -------------
>>
>> PCN Draft Charter (Pre-Congestion Notification)
>>  
>> The PCN WG will tackle the problem of how to provide scalable, 
>> resilient
>>
>> admission control and strong QoS assurance while using packet marking

>> techniques.
>> Current attempts to deliver QoS using only packet marking (e.g.
>> DiffServ) are
>> limited in the level of QoS assurance that can be provided without 
>> substantial over-provisioning. To improve the QoS assurance, PCN will

>> add flow admission control and flow pre-emption. In normal 
>> circumstances admission control should protect the QoS of previously 
>> admitted flows. In times of heavy congestion (for example caused by 
>> route changes due to link or router failure) pre-emption of some
flows
> 
>> should preserve the QoS of remaining flows. While the WG will address

>> both admission and pre-emption, it is assumed that these mechanisms 
>> can be used independently of each other, and the use of one does not 
>> mandate the use of the other.
>>
>> The initial scope of the WG is the use of PCN within a single
DiffServ
> 
>> region.
>> The overall approach will be based on a separation of functionality 
>> between the interior routers and edge nodes of the DiffServ region. 
>> Interior routers mark packet headers when their traffic is above a 
>> certain level, as an early warning of incipient congestion 
>> ("pre-congestion"); this builds on concepts from
>>
>> RFC 3168 "The Addition of Explicit Congestion Notification to IP". 
>> Edge nodes of the DiffServ Region monitor the markings and that 
>> information is used to make flow admission control and pre-emption 
>> decisions. The decisions could be made by the edge nodes or by a 
>> centralized system (which is informed of the edge nodes
measurements).
>>
>> The WG will address the following specific problems and develop 
>> standards track solutions to them:
>> 1. When should an interior router mark a packet (i.e. at what traffic
>> level) 
>>    in order to give early warning of its own congestion?
>> 2. How should such a mark be encoded in a packet (in the ECN and/or 
>> DSCP fields)?
>> 3. How should these markings (at packet granularity) be converted
into
> 
>>    admission control and flow pre-emption decisions (at flow 
>> granularity)?
>>  
>> To support this, the WG will work on the following Informational
>> documents:
>> 1. a Problem Statement, to describe the problems the group is
tackling
> 
>>    and the assumptions made
>> 2. at least two deployment models, initially to help focus the
problem
> 
>> statement
>>    and later to check that the solutions being developed satisfy the 
>> deployment
>>    scenario. Possible deployment models may be: 
>>    (a) IntServ over DiffServ (RFC2998): the DiffServ region is 
>> PCN-enabled
>>        and its edge nodes decide about admission and flow pre-emption
>>    (b) Application-controlled Admission and Pre-emption: routers
> within
>>        the DiffServ region are PCN-capable and trusted 
>> application-controlled
>>        (e.g., SIP) endpoints (gateway or host) based on the marking, 
>> perform
>>        admission and flow pre-emption.
>> 3. a generic analysis of the signaling extensions required to support

>> PCN.
>>    Note that extensions/enhancements to specific signaling protocols 
>>    (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG.
>> 4. at least one example solution implementing the framework and its 
>> performance
>>    evaluation (e.g. simulation results), to provide evidence of the 
>> viability
>>    of the proposed standard in the proposed deployment models 5. an 
>> analysis of the tradeoffs of different encoding possibilities (e.g. 
>> ECN
>>    and DCSP marking)
>> 6. an applicability statement the decision on whether applicability 
>> statement
>>    will be delivered as a standalone document or will be incorporated

>> into other
>>    documents such as deployment models is TBD) 7. an analysis of the 
>> manageability issues of a PCN region
>>  
>> The initial scope of the WG will restrict the problem space in the 
>> following ways:
>> 1. By assuming the PCN-enabled Internet Region is a controlled 
>> environment,
>>    i.e. all the interior routers and edge nodes of the region run PCN

>> and
>>    trust each other
>> 2. By assuming there are sufficient flows on any relevant bottleneck 
>> link in the
>>    PCN-enabled region
>> 3. By focusing on the QoS assurance required by applications
> generating 
>>    inelastic traffic like voice and video requiring low delay, jitter

>> and
>>    packet loss, i.e. as defined by the Controlled Load  Service 
>> [RFC2211].
>> 4. By keeping specific handling of emergency and other precedence 
>> (911, GETS,
>>    WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring 
>> that the edge
>>    nodes are not precluded from taking appropriate actions that may
be
> 
>> necessary
>>    for handling such calls and (b) assuming that PCN Internal Nodes 
>> may not be
>>    MLPP precedence-aware but are DSCP aware.
>>
>> Subsequent re-chartering may investigate solutions for when some of 
>> these restrictions are not in place.
>> 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 impact on e.g. the choice
> of encoding.
>>  
>>
>> Topics out of scope for the WG include a general investigation of 
>> admission control mechanisms.
>>
>> The WG will draw on the substantial prior academic and IETF work on 
>> measurement-based admission control.
>>
>> The WG will work with relevant IETF WGs and, where appropriate, with 
>> external groups.
>>  
>> Milestones:
>>
>> Nov 2006          initial problem statement Internet Draft
>> Nov 2006          initial deployment models Internet Drafts
>> March 2007        initial router marking behavior (including
encoding)
>> Internet Drafts
>> March 2007        initial flow admission control and pre-emption
>> mechanisms Internet Drafts
>>                   (including edge node measurements)
>> March 2007        initial applicability statement Internet Draft
>> March/July 2007   submit Problem statement to IESG for approval as
>> informational RFC
>> July 2007         submit deployment models to IESG for approval as
>> informational RFC
>> July 2007         submit applicability statement to IESG for approval
> as
>> informational RFC
>>                   (may be part of the deployment models)
>> July 2007         initial manageability issues document Internet
Draft
>> Nov 2007          submit router marking behavior to IESG for approval
> as
>> standards track RFC
>> Nov 2007/Mar 2008 submit flow admission control and pre-emption 
>> mechanism as standard track RFC
>> Nov 2007          initial signaling analysis Internet Draft 
>> Nov 2007          submit manageability issues document to IESG for
>> approval as informational RFC
>> Mar 2008          re-charter or close
>>
>> _______________________________________________
>> PCN mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/pcn


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

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