Hi, Let me clear that an abstract information model alone is not likely to satisfy the concern, which is interoperability.
> > 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: [email protected] [mailto:[email protected]] > Sent: Wednesday, June 22, 2011 2:21 AM > 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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
