Hi David, Interoperability would result if no feedback signaling is required. I'm co-author of a draft describing such a solution. Unfortunately the remaining participants of the WG favour signaling based solutions, hence perspectives aren't bright for the draft supported by me.
To me, the WG has worked largely successfully. The mechanisms standardised so far are fairly good. Regards, Ruediger -----Original Message----- From: David Harrington [mailto:[email protected]] Sent: Wednesday, June 22, 2011 4:18 PM To: Geib, Rüdiger; [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, 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
