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: pcn-boun...@ietf.org [mailto:pcn-boun...@ietf.org] On Behalf Of ruediger.g...@telekom.de Sent: 22 June 2011 07:21 To: tom111.tay...@bell.net; ietf...@comcast.net Cc: p...@ietf.org; gen-art@ietf.org; elw...@dial.pipex.com 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: pcn-boun...@ietf.org [mailto:pcn-boun...@ietf.org] On Behalf Of Tom Taylor Sent: Wednesday, June 22, 2011 2:31 AM To: David Harrington Cc: p...@ietf.org; '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 > ietf...@comcast.net (preferred for ietf) > dbharring...@huaweisymantec.com > +1 603 828 1401 (cell) > >> -----Original Message----- >> From: Elwyn Davies [mailto:elw...@dial.pipex.com] >> Sent: Tuesday, June 14, 2011 1:21 PM >> To: philip.eard...@bt.com >> Cc: p...@ietf.org; ietf...@comcast.net; 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, philip.eard...@bt.com 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 > p...@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
