Re: [PCN] lets try again - a chair asking this time

[Bob Briscoe <[e-mail]>]

Michael,

Phil Eardley has suggested this complete re-write, which solves the 
problem you point out, and I think makes the whole thing clearer:
============================================================================
Section 4.2 says:

    o  Police - police, by dropping any packets received with a DSCP
       indicating PCN transport that do not belong to an admitted flow.
       (A prospective PCN-flow that is rejected could be blocked or
       admitted into a lower-priority behaviour aggregate.)

It should say:

    o  Police - drop or re-mark to a lower-priority behaviour aggregate
       i) packets received with a DSCP indicating PCN transport that do not
       belong to an admitted flow and ii) packets that are part of a flow
       that asked to be admitted as a PCN-flow but was rejected.

Notes:

In the existing text the first sentence contradicts the parenthesis. 
It could be interpreted to mean that dropping is the only allowed 
policing action, whereas the parenthesis shows that downgrading was 
also considered appropriate.

Also the existing text used the term 'blocking' as a different action 
to 'downgrading', whereas Section 3.6 just above this text has said 
'"Blocking" means it is dropped or downgraded to a lower-priority 
behaviour aggregate,...'
============================================================================

==Background==
In RFC5559 the term 'block' has been used to mean three different 
actions in two different contexts:

1) Blocking packets:
"  block ECN-capable traffic that uses the same DSCP as PCN from
    entering the PCN-domain directly.  "Blocking" means it is dropped or
    downgraded to a lower-priority behaviour aggregate, or alternatively
    such traffic may be tunnelled through the PCN-domain"

2a) Blocking rejected flows:
"    (A prospective PCN-flow that is rejected could be blocked or
       admitted into a lower-priority behaviour aggregate.)"
2b) Blocking flows
"   ...whether to admit or block a new flow..."

So for packets (1), 'block' is defined to mean any of drop, downgrade 
or tunnel, but for rejected flows in this one case (2a) 'block' is 
being used to only mean drop, but throughout the rest of the doc (2b) 
'block' is used as just the opposite of admit, as a general term that 
I assume may be associated with various actions.


Bob


At 09:24 23/03/2012, Michael Menth wrote:
>Hi Bob,
>
>Am 23.03.2012 00:53, schrieb Bob Briscoe:
>>Scott,
>>
>>If an erratum is rejected, we'll have to update the architecture via 3-in-1.
>>
>>Therefore, we'll have to post the erratum quickly, so that we know 
>>whether it has been rejected or not before 3-in-1 gets thru the RFC-Editor.
>>
>>Here's the erratum I will post unless anyone can suggest a better way:
>>
>>====================================================================
>>RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009
>>Source of RFC: pcn (tsv)
>>
>>Type: Technical
>>
>>Reported By: Bob Briscoe
>>Date Reported: 2012-03-XX
>>
>>Section 4.2 says:
>>
>>    o  Police - police, by dropping any packets received with a DSCP
>>       indicating PCN transport that do not belong to an admitted flow.
>>       (A prospective PCN-flow that is rejected could be blocked or
>>       admitted into a lower-priority behaviour aggregate.)
>>
>>
>>It should say:
>>
>>    o  Police - police, by dropping or re-marking the DSCP of any packets
>>       received with a DSCP indicating PCN transport that do not belong
>>       to an admitted flow. (A prospective PCN-flow that is rejected could
>>       be blocked or admitted into a lower-priority behaviour aggregate.)
>>
>>
>>Notes:
>>
>>The change makes the first sentence consistent with the 
>>parenthesis, otherwise the two contradict. The first sentence as it 
>>stands could be interpreted to mean that dropping is the only 
>>allowed policing action, whereas the parenthesis shows that 
>>downgrading was also considered appropriate.
>
>What does block in the parentheses mean? The same as reject? Or does 
>blocking imply dropping instead of remarking the DSCP? I find the 
>text clearer without the parentheses. Re-marking the DSCP must imply 
>downgrading (could be added) which does not exclude admission into a 
>lower-priority behavior aggregate.
>
>Regards,
>
>      Michael
>
>
>>====================================================================
>>
>>
>>Bob
>>
>>At 20:35 22/03/2012, Bradner, Scott wrote:
>>
>>>On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote:
>>>
>>> > Ruediger,
>>> >
>>> > [Scott, a question for you at the end]
>>> >
>>> >
>>> >
>>> > I prefer your erratum suggestion because it flags the problem 
>>> in the doc that now needs clarifying, so it's more likely to be 
>>> noticed by people reading the deprecated text. But we'll have to 
>>> see whether this would be accepted as an erratum. The relevant rule is #7 here:
>>> > <http://www.ietf.org/iesg/statement/errata-processing.html>
>>> >
>>> > "Changes that modify the working of a protocol to something 
>>> that might be different from the intended consensus when the 
>>> document was approved should be either Hold for Document Update 
>>> or Rejected. Deciding between these two depends on judgment. 
>>> Changes that are clearly modifications to the intended consensus, 
>>> or involve large textual changes, should be Rejected. In unclear 
>>> situations, small changes can be Hold for Document Update. "
>>> >
>>> > If we wrote an erratum to RFC5559, it would be legitimate, 
>>> because the para you have quoted has two contradictory statements 
>>> in it anyway. I doubt an erratum can refer to an RFC published 
>>> later (3-in-1), because errata are meant to correct what the 
>>> document should have said at the time. I think we could compose 
>>> an erratum that resolved the contradiction in that paragraph 
>>> while at the same time making it "not inconsistent" with what we 
>>> now want to say in 3-in-1.
>>> >
>>> > Scott, can you advise?
>>>
>>>that sounds logical
>>>
>>>Scott
>>
>>________________________________________________________________
>>Bob Briscoe,                                BT Innovate & Design
>>_______________________________________________
>>PCN mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/pcn
>
>--
>Prof. Dr. habil. Michael Menth
>University of Tuebingen
>Faculty of Science
>Department of Computer Science
>Chair of Communication Networks
>Sand 13, 72076 Tuebingen, Germany
>phone: [phone]
>fax: [phone]
>mailto:[e-mail]
>http://kn.inf.uni-tuebingen.de

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design