Re: [Gen-art] [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

["Georgios Karagiannis" <[e-mail]>]

Hi all,

I agree with Phil regarding the fact that the Information model can be
described as an abstract model informally to show the relationships
between objects. In particular RFC 3444 mentions:

   "IMs can be defined in an informal way, using natural languages such
   as English.  An example of such an IM is provided by RFC 3290 [9],
   which describes a conceptual model of a Diffserv Router and specifies
   the relationships between the components of such a router that need
   to be managed."

Regarding the possible options to support interoperability, I also think
that the latter might be plausible. I see three options of implementing
this:

1) each PCN edge behaviour draft will contain such an information model

2) a default information model will be included in the signaling
requirements draft

3) a new draft should be started by the PCN WG to describe such an
information model


With which option should we proceed?


Please also note that I have started modifying the following draft that
can be used as an example of how a signaling protocol can be applied to
support an PCN edge behaviour.
http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01

The target is to submit this draft to tsvwg. However, I do not think that
I will be able to submit this draft before the submission deadline (4th
of July). Tom and Francois were willing to help on commenting and/or
contributing to this.


Best regards,
Georgios




On 6/22/2011, "[e-mail]" <[e-mail]> wrote:

>Personally I think it unlikely that the WG would ever complete the former
>
>The latter might be plausible, though having flicked at 3444 i can't tell exactly what we're missing. It seems to say that an information model is an absrtact model about relationships between objects and can be defined informally - (since I havent consciously written one, I'm being vague) - the combination of CL & signalling reqts seems quite close to this?
>
>Thanks for progressing Tom.
>phil
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
>Sent: 22 June 2011 07:21
>To: [e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08
>
>Hi Tom,
>
>which work are you taking up?
>
>- specifying the madatory to implement protocol.
>- or specifying a minimum clear information model (RFC3444).
>
>I prefer the latter above the former.
>
>
>Regards,
>
>Ruediger
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Tom Taylor
>Sent: Wednesday, June 22, 2011 2:31 AM
>To: David Harrington
>Cc: [e-mail]; 'Elwyn Davies'; 'General Area Reviwing Team'
>Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08
>
>OK, I'll take up the good work. Just to start with, I propose to submit
>interim updates as I wished I had back a few months ago. I'll go on from
>there.
>
>On 21/06/2011 3:49 PM, David Harrington wrote:
>> Hi,
>>
>> The WG was chartered to specify the
>> (3) encoding and transport of (pre-)congestion information
>>   between the interior and domain egress
>> ... and ...
>> (5) encoding and transport of (pre-)congestion information
>>   between the egress and the controlling domain ingress
>>
>> I interpret that to mean the transport protocol and the message
>> formats should be specified in the documents.
>> I have to agree with Elwyn that lack of such formats means
>> implementations are likely to not be interoperable.
>> I am not sure what protocols would be suitable for these tasks; other
>> readers may have similar concerns.
>>
>> I think the specification would benefit from a mandatory-to-implement
>> protocol expected to carry the configuration and reported information.
>> At a minimum, there should be a clear information model (RFC3444)
>> about the information to be transported.
>> The data type and range of values should be included in the
>> information model for each counter and configuration variable.
>> I think it would be better to specify a mandatory-to-implement
>> protocol, or at least a recommended-to-implement protocol, and a
>> corresponding data model to ensure interoperability.
>>
>> David Harrington
>> Director, IETF Transport Area
>> [e-mail] (preferred for ietf)
>> [e-mail]
>> [phone] (cell)
>>
>>> -----Original Message-----
>>> From: Elwyn Davies [mailto:[e-mail]]
>>> Sent: Tuesday, June 14, 2011 1:21 PM
>>> To: [e-mail]
>>> Cc: [e-mail]; [e-mail]; General Area Reviwing Team
>>> Subject: Re: Gen-art LC review of
>> draft-ietf-pcn-cl-edge-behaviour-08
>>>
>>> Hi, Phil.
>>>
>>> It strikes me that the first and second points below are
>>> something which
>>> David Harrington perhaps ought to give an opinion on. He has got to
>>> defend it to the IESG.
>>>
>>> On the first point, my feeling is that neither the
>>> requirements doc nor
>>> this doc is sufficient to guarantee an interoperable implementation.
>>
>>> There seems to me to be a cleft stick here (irrespective of
>>> whether this
>>> ends up as informational or experimental.) The WG is is specifying
>>> pieces of functionality that go in two or more different
>>> types of boxes
>>> (three if there is a separate implementation of the central decision
>>
>>> point). If the system is going to be generally deployable or
>>> even to be
>>> experimented with there may be different implementations.
>>> The box types
>>> communicate using the information specifications in the doc.  This
>>> appears to require protocol definitions.  Where they are defined is
>>> another issue but I feel it has either to be in this doc or
>>> in another
>>> doc referenced from this.  If they aren't specified I can't see that
>>
>>> anybody will be interested in making commercial implementations.
>>>
>>> I see David didn't make any comment about this situation in his
>> write
>>> up, so maybe I am over reacting.
>>>
>>> Regards,
>>> Elwyn
>>>
>>>
>>>
>>>
>>>
>>> On 13/06/2011 18:04, [e-mail] wrote:
>>>> Elwyn,
>>>>
>>>> Thanks for the detailed review.
>>>> A few follow-ups in-line
>>>> Thanks
>>>> phil
>>>>
>>>> --
>>>> Major issues:
>>>> The draft contains partial definitions of two control
>>> protocols (egress
>>>> ->   decision point; decision point ->   ingress).  It does
>>> not make it
>>>> clear whether the reader is expected to get full
>>> definitions of these
>>>> protocols here or whether there will be another document
>>> that specifies
>>>> these protocols completely.  As is stands one could build
>>> the protocols
>>>> and pretty much guarantee that they would not be interoperable
>> with
>>>> other implementations since message formats are not
>>> included although
>>>> high level specs are.  The document needs to be much
>>> clearer about what
>>>> is expected to happen here.
>>>>
>>>> [phil] there is another document, " Requirements for
>>> Signaling of (Pre-) Congestion Information in a DiffServ
>>> Domain"
>>> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme
>>> nts-04] that deals with your issue to some extent. It doesn't
>>> specify message formats but does at least specify better what
>>> information the messages must contain. My understanding is
>>> that unfortunately the WG doesn't feel it has the effort to
>>> specify these protocols completely.
>>>>
>>>>
>>>> Use of EXP codepoint: My understanding of what is said in
>>> RFC 5696 is
>>>> that EXP is supposed to be left for other (non=PCN) systems to
>> use.
>>>> This draft uses it.  Is this sensible? Is this whole draft
>>> experimental
>>>> really?
>>>> [phil] the intention of rfc5696 was that the EXP codepoint
>>> is for experimental *PCN* encodings - ie beyond the baseline.
>>> For instance, the CL behaviour needs separate codepoints for
>>> (PCN) threshold-marking and (PCN) excess-traffic-marking&
>>> this would require using the EXP codepoint.
>>>> However...... There is currently some discussion on what
>>> PCN encodings to specify beyond the baseline. At the time we
>>> wrote the baseline, we envisaged the need for several
>>> encodings - however it now seems that one may be enough, in
>>> which case there may possibly be just one PCN encoding (ie a
>>> revised 5696 that now uses the 01 codepoint), so possibly may
>>> be Standards track - ??
>>>> Anyway, i take your point that we need to think about Status.
>>>>
>>>> s3.3.1:
>>>>> [CL-specific] The outcome of the comparison is not very sensitive
>>>>>         to the value of the CLE-limit in practice, because
>>> when threshold-
>>>>>         marking occurs it tends to persist long enough that
>>> threshold-
>>>>>         marked traffic becomes a large proportion of the
>>> received traffic
>>>>>         in a given interval.
>>>> This statement worries me.  It sounds like a characteristic of an
>>>> unstable system.  If the value is that non-critical why are we
>>>> bothering?
>>>>
>>>> [phil] admission control system. imagine the pcn-domain has
>>> one bottleneck link. If it can cope with the current number
>>> of calls (their bandwidth), then no pkts gets
>>> threshold-marked, so the CLE = 0. If there are too many, then
>>> all pkts gets threshold-marked, so the CLE = 1. If there is
>>> almost exactly the right number of calls, then
>>> threshold-marking will tend to be on for a while, then off
>>> for a while (perhaps when several flows are transmitting less
>>> traffic than normal), so the CLE will jiggle about between 0&
>>>   1. If the CLE is<   CLE-limit (say CLE-limit = 0.6&   current
>>> CLE = 0.5), when a new call admission request happens to
>>> arrive then it gets admitted. But then there's more traffic
>>> and it's likely that the CLE will rise to 1 - hence another
>>> admission request will get blocked. When a call finishes,
>>> then the reverse is true.
>>>>
>>>> Now suppose we had in fact configured CLE-limit = 0.4, then
>>> in the scenario above the call request would have been
>>> blocked. However, (1) the PCN-domain has only admitted one
>>> fewer call, (2) a short time later, either the CLE happens to
>>> be lower or a call departs, and then the next admission
>>> request is accepted.
>>>>
>>>> All this means that it doesn't matter much exactly what you
>>> set CLE-limit to - it barely affects the average number of
>>> calls admitted. The argument above is hand-wavy, but lots of
>>> simulations have been done that show this is true (I hope i'm
>>> representing the results correctly)
>>>> So the lack of sensitivity to CLE-limit seems like a good thing.
>>>>
>>>>
>>>> Minor issues:
>>>>
>>>> s6:  The potential introduction of a centralized decision
>>> point appears
>>>> to provide additional attack points beyond the architecture
>>> in RFC 5559.
>>>> It appears to me that the requests for information about
>>> specific flows
>>>> to the ingress are ighly vulnerable as they (probably)
>>> contain all the
>>>> information needed to craft a DoS attack on the flow.
>>>>
>>>> [phil] seems a good point to me
>>>>
>>>
>>>
>>> --
>>> Join the Cambridge Oxfam Walk on Sunday 15 May, 2011.
>>> For more information, see
>>> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and
>>> follow us on Twitter at http://twitter.com/CambOxfamWalk.
>>>
>>>
>>
>> _______________________________________________
>> PCN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcn
>>
>>
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn