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, "[email protected]" <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >[email protected] >Sent: 22 June 2011 07:21 >To: [email protected]; [email protected] >Cc: [email protected]; [email protected]; [email protected] >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: [email protected] [mailto:[email protected]] On Behalf Of Tom >Taylor >Sent: Wednesday, June 22, 2011 2:31 AM >To: David Harrington >Cc: [email protected]; '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 >> [email protected] (preferred for ietf) >> [email protected] >> +1 603 828 1401 (cell) >> >>> -----Original Message----- >>> From: Elwyn Davies [mailto:[email protected]] >>> Sent: Tuesday, June 14, 2011 1:21 PM >>> To: [email protected] >>> Cc: [email protected]; [email protected]; 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, [email protected] 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/pcn >> >> >_______________________________________________ >PCN mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/pcn >_______________________________________________ >PCN mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/pcn >_______________________________________________ >PCN mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
