Subject: A discussion of metadata in ForCES

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Oct 2003 12:26:39 -0400

I've submitted a personal Internet-Draft, which hasn't made it into
the archives as of yet.  It presents a model and vocabulary for
discussing the concept of "metadata", within the context of ForCES.  The
draft hasn't yet been published in ietf.org, so I put it on my personal
web server:

http://www.striker.ottawa.on.ca/~aland/draft-dekok-forces-metadata-00.txt

---
   Abstract

   This document describes a model for discussing metadata in ForCES.
   It defines multiple kinds of metadata, and shows which ones are in
   scope for ForCES, and which ones are out of scope for ForCES.  It
   further defines a vocabulary for discussing metadata, which should
   help to avoid much of the historical confusion and disagreement
   surrounding discussions of metadata.
---

  From what I've seen of discussions about metadata, it appears that
people are using the word "metadata" to mean a number of different
things.  They're all related, so it appears that people are
communicating.  However, because they're subtly different, that
communication ends up failing with mutual incomprehension.

  The draft discribes the different variants of metadata, and proposes
vocabulary which should help minimize confusion surrounding the concept
of "metadata".

  The draft does NOT get into any vendor-specific description of
metadata, and it does not propose any standard for describing the
format, content, or interpretation of metadata by elements in the
network.  Instead, it deals with human-level communication issues.

  Alan DeKok.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Oct 2003 13:38:10 -0400

[The document is available:
  http://www.ietf.org/internet-drafts/draft-dekok-forces-metadata-00.txt]

I think this is a good first step in teasing apart the various assumptions
people make about metadata.  One question occurred to me reading the
document.  After explaining the (useful) distinction between implicit and
explicit metadata, you go on to describe implicit metadata as something
Forces should be concerned with.  This could mean one of three things:

1) That in the dicussion of Forces protocol, operations, and usage we
should be aware  of implicit metadata and the fact that systems will make
use of it.
2) That we should include in the description of LFBs and LFB metadata
interaction the implicit metadata, for the purpose of error-checking the paths.
3) That the protocol descriptions of LFBs and information passing need to
explicitly indicate the implicit metadata as well as the explicit metaqdata.

Choice 1 is clearly the case.
Choice 2 is attractive, but I think it may be an attractive nuisance.  That
is, I think that trying to describe every aspect of implicit metadata and
the checks we could perform on the graph is not particularly useful and can
cause problems.
Choice 3 appears unnecessary.  Implicit metadata is passed whether we talk
about it in the protocol or not.  We can not change that, nor affect its
meanings.

Yours,
Joel M. Halpern

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Oct 2003 14:25:45 -0400

"Joel M. Halpern" wrote:
>  After explaining the (useful) distinction between implicit and
> Forces should be concerned with.

  Yes.  We need to be able to say in the model "this thing in the
network operates under these assumptions."  Those assumptions may never
be sent across the wire, but they still exist.

>  This could mean one of three things:
>

  Yes.

> interaction the implicit metadata, for the purpose of error-checking the paths.

  Yes.  I do not see this as contradictory to #1.

  The "implicit" metadata is implicit only in the network.  That
metadata *is*, however, explicit in the humanly-readable specification
of the network.

> explicitly indicate the implicit metadata as well as the explicit metaqdata.

  In some cases, this information may be useful.  In other cases, it may
not be useful.

> the checks we could perform on the graph is not particularly useful and can

  I agree.

  e.g. When modelling an IPv4 forwarder, it's not very useful to have
every path in the model labelled as "this path implicitly assumes that
it only transports IPv4 packets"

> about it in the protocol or not.  We can not change that, nor affect its

  ForCES is more than just the protocol.  I see it as *very* useful to
have explicit statements in the specs, as to how the system works, and
what is expected from an implementation.

  e.g. For the same IPv4 forwarder, it may be useful to have IN THE
MODEL ONLY, a statement that "the input to this LFB assumes that the TTL
of the packet has already been decremented".  Any automated model
validator, or emulation of the system, can use that metadata to mark up
packets with metadata which WILL NOT be transported in the actual
system.  However, that same metadata may be incredibly useful in
debugging problems like "why the heck isn't the TTL decremented?"

  While that information will never be explicitly represented in the
real system, it is still useful for describing the expected behaviour of
the system, from the perspective of the model.

  Alan DeKok.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Oct 2003 14:46:28 -0400

There is a big difference between requiring that LFBs document their
"preconditions" (and "postconditions") and trying to formally specify such
things.
This relates to discussions about formally specifying the behavior of
LFBs.  I would prefer not to try to do that, and to leave the description
to the "documentation". I do not think we should try to provide generalized
computer checkable pre / post condition checking, (or even worse
generalized processing checking.)

Even if one thinks that such a capability (computerize condition checking)
would be useful, I would think we would want to defer that work till later
and get the basics working first.

Yours,
Joel

PS: I actually very much like pre and post conditions.  I find the work
Dijkstra did in formalizing this very useful.  Useful to me, not the compiler.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Oct 2003 15:24:01 -0400

> "preconditions" (and "postconditions") and trying to formally specify such

  While my goal is to formally specify such things, I currently don't
know how to do so.  That's why the document was vague as to
implementation details.

> and get the basics working first.

  Absolutely.  The intention of the document was to cut short the
circular discussions of metadata which I've seen in the past.  Once we
have a common vocabulary for communication, we can then later work on
defining computer representations of our intentions.

  Alan DeKok.