Hi, The main thing you are missing is an explanation of how you will achieve interoperability. The charter calls for specification of the encoding and transport of the information between points in the system: > > (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
How will the information get from the interior to the domain egress, if the PCN processing for the interior node is implemented by vendor A and the PCN processing for the domain egress node is implemented by vendor B? In what message format will vendor A send it so that it can be interpreted consistently by the receiver, regardless of which vendor implements the receiver? What format validation shoudl be performed by teh receiever, what conditions constitute a receiving error, and what error codes should be returned by the receiver that will be understood by the sender? Ditto for the players in 5) The specification as written seems imcomplete because it does not deal with specifying the encoding and transport of the information. Am I just missing it, or is it really just not there? An information model can help to understand the properties of the data to be transported, but it doesn't really solve the problem of transporting the data in a standardized, interoperable manner. You will need to work hard to convince me that there is strong TECHNICAL justification for not providing REQUIRED (or at least RECOMMENDED) protocols and message formats/data models involved. I would likely need to work hard subsequently to convince the IESG. If the problem is that the WG has no energy, we can solve that in a much simpler way than updating these documents - we can just close the WG. If the WG doesn't have enough energy to complete these documents first, we can abandon the documents. That could save everybody a lot of time - WG editors, WG reviewers, WG chairs, the AD, IETF Last Call reviewers from various directorates, the IESG, IANA ... I think the Internet would benefit from this technology, and I would consider abandoning these documents at this point an awful waste of time, given how much work has been put into them already, so I STRONGLY encourage the WG to find the energy to complete their agreed-upon deliverables, but if it is WG consensus to abandon them, I guess I would have to accept that WG consensus. David Harrington Director, IETF Transport Area ietf...@comcast.net (preferred for ietf) dbharring...@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: philip.eard...@bt.com [mailto:philip.eard...@bt.com] > Sent: Wednesday, June 22, 2011 4:17 AM > To: ruediger.g...@telekom.de; 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 > > 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
