Re: First cut at AAA draft

[David Frascone <dave@frascone.com>]

Below are some comments I received privately (they were previously
posted to this list), and all of them that I could respond to.  Many
of the questions/comments are unanswered.


>Comments on AAA draft
>Brad Chen
>21 March 2001
>
>Here's some comments on the AAA draft. I've made a modest effort to
>organize/structure them for easier consumption.
>
>======================================================================
>General Comments
>======================================================================
>
>G1. The draft appears mentions the option of both online and
>offline uses of this data. (See specifically section 3). That implies
>that requirements will tend to need to support online data usage,
>which in general is more demanding than offline processing.

   I think the solution should allow for both online and offline
   processing.  Since the solution from the AAA working group does
   both, I don't think having it as a requirement (even an implied
   one) is a problem.  -- Anyone else agree/disagree?

>G2. Is QoS out of scope for this? From the comment at the end of
>section 3 it's not clear. I'd suggest that it would be nice to 
>avoid requirements that would tend to preclude CDIs from adding QoS as
>a value-add that was compatible with but out-of-scope of the relevant
>standards. A relevant comment in the draft is where it says "These
>downstream tiers are out-of-scope." I'd like to read this as
>'requirements for these tiers are out of scope, but we do intend to
>craft requirements that are not incompatible with this functionality.'

   I agree.  I have modified the text, but I'm not completely happy
   with the modified sentance either.  If anyone can come up with better
   text, I'll apply it.

      The requirements for these downstream tiers are considered 
      out-of-scope, but the solution should not be incompatible
      with this functionality.

>G3. That SLA validation and differentiated service levels might be
>worth consideration at this time. Justification is that they enable
>different kinds of business.

   This is one of the comments I had as well.  (Well, not for SLA
   validation specifically, but authentication (validation) in
   general)

   Should we specify the requirements for the other two A's of AAA
   now?  (Authentication and Authorization)?

>G4. Seems like we need to get some more real-world information on billing.
>How does billing/settlement happen in other domains? Can we learn from
>them? Some relevant domains: 
>- telephone networks
>- peered ISPs
>- existing CDNs (akamai, mirror image)
>- stream distribution networks like RBN
>Are there settlement models from different but related industries
>that CDIs will be encouraged/oblidged to adopt due to business models
>due to management practices inherited from other industries?
>Are there other billing models that the CDI accounting will be
>expected/required to interoperate with? For example, incorporated
>transmission charges?

   I know that historically, telco accounting has all been batch
   jobs running on huge mainframes.  But, as of about 10 years ago,
   most carriers were frantically trying to redo all the accounting
   to allow for pre-paid calls.  I helped convert one system from
   batch to real-time accounting, and it was a MAJOR undertaking.
   Given this, I think if we mandate realtime, and allow batch,
   then everyone will be happy.

   Outside of the batch-vs-realtime issue, I'm not aware of any
   accounting issues that anyone has ever run into.

>G5. An implication of current draft is that the cost of things like
>storage, which don't correspond to any specific event, are out of
>scope. Can somebody confirm this? If not we should maybe discuss.
>A sketch of a use-case where these costs are relevant: consider 1000
>request for the same image "foo.gif" vs. 1000 requests from a catalog 
>with 10000 images. The latter requires much greater edge storage to 
>achieve the same performance levels. Similar problems arise for 
>frequently vs. rarely used content. Will it be possible to handle all
>these costs statically?

   I don't think storage is in scope for an AAA requirement.  We
   are picking an AAA protocol/architecture here, not a particular
   server/implementation.  The storage requirements of this document
   are that a particular AAA server does not drop packets when it is
   not able to immediately deliver the accounting information, and
   that it stores the CDR in a persistant manner.

>G6. Is a composite CRD a summary? It could be quite hard to anticipate
>the kinds of summaries that will be needed, especially if there is no
>prior art to reference. Examples:
>- summary by URI for content provider
>- summary by "user" or "session" for access provider
>What specifically is intended here?

>G7. Is there an intention to support services for non-cacheable content?
>- Should the accounting model generalize to multicast events?
>- Should the accounting model generalize to real-time conferencing 
>(audio or video or both)?

>G8. The namespace discussion herein left me with more questions than
>answers. Clearly naming cuts across all three requirements drafts in
>discussion; I'm wondering if it needs to be considered in an
>independent document. There is also some naming wierdness introduced
>by DNS-based RR schemes, as the document will have multiple names as a
>side effect of request routing. Can anybody explain how things are
>supposed to fit together?

>G9. I've got a number of related concerns around the topic of the CDR
>timestamps:
>G9a. 5.3.2 I would like to suggest a more accurate timestamp. I'm
>assuming that with a long==32-bit timestamp you can only achieve
>resolution down to a second, like a UNIX time value or something.
>The overhead of a 64 bit timestamp would have a minimal impact on
>overhead and could make the records much more effective for things
>like sub-second SLAs. Millisecond accuracy would be nice.

   I don't have any objection to converting to 64bit timestamps.

>G9b. Will there always be both a "start" and a "complete" record 
>for all CDRs? This would be nice property to have. If this were the
>case, you would really like a UUID as a part of the records, to make
>it possible to match a "complete" record to the corresponding "start"
>record. Note that the UUID typically also contains an accurate
>timestamp.

   I think there needs to be some way to tell the completion of an
   event so that billing can be stopped.  This was a major problem
   in RADIUS implementations of dynamically assigned address pools.

>G9c. Any provision for duplicate detection in CDR records? Again a
>UUID would help with this. (6.5: Imagine a CDR is transferred back 
>through a sequence of CDNs. Imagine server reboots and such that make 
>multiple transmissions possible. Seems like you would like to have a 
>UUID with each record so you can detect duplicate records.)

   Duplicate handling is an implicit part of the Diameter.  

   Perhaps we should specify handling of duplicates as a requirement of
   the proposed AAA protocol.

>G10. Could there be a provision for an extension or an optional field
>that would specify a specific surrogate within a source or sink in a 
>CDR? Could be either an opaque field from a namespace defined by the 
>CDN, or a globally unique value like a GUID or an Ethernet address.
>If we prohibit this information we will tend to preclude use of this
>information for system diagnostics etc.

   We are specifying the *minimum* requirements for an AAA server.  I
   think any solution we find will be able to handle any optional
   fields we need to define in the future.

>G11. Origin_ID and CDN_ID - Strings? What is the namespace for these
>strings? Also, maybe we could make this slightly more generic; terms
>like "source" and "dest" would not imply that the source was the
>originator of the content which isn't always going to be the case...
>
>==============================================================================
>Less focused questions
>==============================================================================
>
>G7. To what degree are accounting service providers possible/required?
>G8. What privacy concerns need to be addressed by this model?
>G9. Is there an intention to support billing based on delivered performance?

   I don't think these questions really affect this document.  However, 
   they are something to consider in the general architecture.

>==============================================================================
>Nits
>==============================================================================
>
>Q: "These downstream tiers are considered out-of-scope"
>This is a sentence fragment.

   It passed my parser.  Could you (or someone) please supply better
   text.
>
>Q: 5.2.3 Does this overlap with work occurring in the RRS work group?
>
>Q: Just to make sure I understand, the datatypes referred in
>section 5.3.1 would be defined as a part of protocol definition, as
>opposed to requirements definition. Is this the intention here?

   I think the intention is to say that the protocol must be able
   to transmit the given types.
>
>5.3.2 I assume that "complete" means the injection has completed from
>the source perspective but not necessarily that distribution within
>the destination perspective.
>
>5.3.5 Does the "miss" necessarily go all the way back to the origin?
>It could be handled by an intermediate CDN couldn't it?
>
>Here's a nit: "Gilletti et. al." => "Gilletti et al."

   That's a difficult change to make, since it is dynamically
   generated by xml2rfc.tcl.

   Let me know if you want me to inform the author and modify the program.

>5.3.5 Can we have a provision here to include optional QoS information
>here? Otherwise this accounting information would tend to preclude
>differentiated service levels. QoS could be expressed as a part of
>"ContentType" but that seems to me like a bit of a hack.
>
>Q: In general, how worried are we about the size of these records?
>
>Q: Longs might not be long enough for measuring the length of some
>streaming content. Better use a 64-bit field.
>
>Nit: Receiver => Reciever

   To quote the rhyme, "I before E, *except* after C".  My spell
   checker agrees with the rhyme.

>Q: Does the RecieverID identify a desktop? Or a session?
>What are the relevant privacy concerns in this context?
>
>5.3.6: I don't understand the editor's note. Can you elaborate?

   It was removed from the new document.

>Q: I think we may eventually need to consider a tradeoff between
>requirements about "Guarenteed Delivery" and the cost of
>accouting. It might be nice if the cost of accounting was always small
>compared to the cost of the service, even for things like caching of
>small images.

-- 
David Frascone

              Trees hit cars only in self-defence.