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

[Michael Menth <[e-mail]>]

That's fine with me.

Michael

Am 23.03.2012 20:29, schrieb Bob Briscoe:
> 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

-- 
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