perfsonar development work

Author: boote
Date: 2007-10-30 12:56:01 -0400 (Tue, 30 Oct 2007)
New Revision: 294

Modified:
   branches/owd/rnc/summary.rnc
Log:
Resolved comments removed. vv will add 'schedule' parameter.

jeff


Modified: branches/owd/rnc/summary.rnc
===================================================================
--- branches/owd/rnc/summary.rnc        2007-10-29 03:51:36 UTC (rev 293)
+++ branches/owd/rnc/summary.rnc        2007-10-30 16:56:01 UTC (rev 294)
@@ -67,42 +67,8 @@
                 SummaryParameter+
         }
         
-# parameters as indicated by mail
-
+# XXX: Add 'schedule' parameter
 SummaryParameter = 
-# What is percentile here for?
-# You can use the 'buckets' in the data portion to compute *any*
-# percentile... Is this just a way of pre-computing some specific
-# percentiles and reporting them more directly?  If so, it probably
-# still belongs in the data section, wouldn't it?
-#
-# The point of the metadata section is for things that do not change
-# for each new data set. Percentile would be different for every single
-# one most likely.
-#
-# If you want to move this into 'data' somehow, I would be ok with that.
-# But, it is not metadata.
-#
-# VV begin:
-# The idea was to ask for a certain percentile, which (like other 
-# aggregations) can be computed by the service.
-# I think, it does not make sense, to report a percentile in the data 
-# section without giving the possibility to say _which_ percentile should
-# be reported.
-# So either we have this as a parameter and a corresponding value in the 
-# data section, ot we do not have it at all.
-# I tend to the latter (if the need arises, we can add this later on and
-# still be downwards compatible). As you said, this can also be computed 
-# by the buckets.
-# VV end.
-#
-#        element nmwg:parameter { 
-#                attribute name { "percentile" } &
-#                (
-#                        attribute value { xsd:string } |
-#                        xsd:string
-#                )
-#        } &
         element nmwg:parameter { 
                 attribute name { "bucket_width" } &
                 (
@@ -110,25 +76,6 @@
                         xsd:float
                 )
         } &
-# I don't know what this is... Commenting out for now, you can add
-# it in if you can explain to me what it is.
-#        element nmwg:parameter { 
-#                attribute name { "sub_cout" } &
-#                (
-#                        attribute value { xsd:unsignedInt } |
-#                        xsd:unsignedInt
-#                )
-#
-# VV begin:
-# this was a typo: "sub_count" would have been the right word. This
-# would correspond to the "groupsize" in our (hades) case. I'm not
-# sure about the name, though. As we are sending packet trains, it
-# represents the number of packets in one train.
-# VV end.
-# 
-# We may want to include other information about the schedule here,
-# things like sending rate.
-        }
 
 
 SummaryData =
@@ -148,96 +95,6 @@
                 )
         }
 
-#
-# not sure about the following stuff
-# . from/to (part of metadata, sender_port and receiver_port can be part of 
the
-#   parameter set, which should be filled in only by the service?)
-#
-#start-jwb
-# I suppose this is possible, but port is something that changes for each 
test
-# in my AMI implementation. I do not keep it in 'summary' stats because it
-# would not allow for aggregation of the data.
-#end-jwb
-#
-# VV begin:
-# in our implementation at the moment, you can specify the port numbers. It
-# is possible (but unlikely) to have two measurements on the same route with
-# same parameters but running on different ports (I'm quite sure that this
-# would not make sense unless you are also changing some more parameters
-# like packet size, in which case it would be unambiguousl even if you do not
-# know the port number). We could maybe take this in as an optional parameter
-# in the metadata set, but leave it out in the summary...
-# VV end.
-# 
-# . same goes for "sync" and "sent"
-#
-#start-jwb
-# sync just indicates if both clocks were synchronized at the time of the 
test.
-#
-# VV begin:
-# we have a problem there, as we are not reporting the sync status in our
-# data files
-# VV end.
-#
-# sent is required for most of the rest to make any sense. Lost, dups are
-# really only useful if you know how many packets were sent...
-#
-# VV begin:
-# as we (hades)are sending packet trains, all our statistics are relating to 
-# one packet train. The number of packets in this train is given by the 
-# somewhat ominous styled "sub_count" (see above, should be discussed).
-# if we are going to give out a summary for the whole time-span, we have to
-# change quite some things in our output format. 
-# Visualisations like psUI rely on the per-train summarization to show a 
-# continuous graph over a longer time span.
-# VV end.
-#
-#end-jwb
-#
-# . added ipdv (IP delay variation aka jitter)
-#
-#start-jwb
-# You can't add this without specifying what 'definition' of jitter you
-# are using. I would prefer to leave it off. Again, this can be directly
-# determined based on the 'buckets' that are here.
-#end-jwb
-#
-# VV begin:
-# the term "jitter" is wrong here (sorry my mistake), what we are reporting
-# conforms to the definiton of ipdv in the IPPM RFC (at least I think so.
-# this needs maybe some verification). Again, psUI is visualising this kind
-# of data, so we should report it. 
-# VV end.
-#
-# . possible other bucket definitions?
-#
-#start-jwb
-# sync should just be done as part of 'nmtime' elements. The delay
-# values should not be floats - they should be nmtime elements.
-# By convention, we could specify that the 'sync' value of StartTime
-# indicates the sync status.
-#
-# VV begin:
-# I checkes nmtime.rnc and found that the nmtime element needs to have
-# an absolut timestamp. And there we have a problem: a delay value is only
-# a duration. We are reporting absolut timestamps per packet train, not per
-# delay. Of course we can just take this timestamp but then we are indicating
-# something wrong, as it is (maybe) not the timestamp of (e.g.) the maximum
-# delay measurend in the group of packets.
-# This timestamp is already reported in the form of an nmtime element (see 
-# StartTime and EndTime elements).
-# So there is no added benefit (from our point of view) to make the delay
-# values real nmtime elements. And it would not add more information
-# as we do not have more. On the other hands, we would have considerable
-# effort, to report the real timestamps.
-# VV end.
-#
-# I'm not sure about the port numbers...  I'm ok with them being optional
-# 'data', but I would not want them in the metadata part. They vary too
-# much.
-#end-jwb
-# VV: port numbers: see above.
-#
 SummaryDatum =
         element summary:datum {
 # The synchronization attribute in the precision part of StartTime
@@ -246,18 +103,16 @@
 # If is is known that any of the packet measurements were made with
 # unsynchrnonized clocks, then the synchronization attribute of the
 # StartTime SHOULD be set to False.
-#
-# VV begin:
-# I'm OK with that, and I think it is sufficient to report the sync status
-# for the whole session (or per packet train, in our case).
-# VV end.
-#
                 StartTime &
                 EndTime &
                 (
                     attribute sent { xsd:unsignedInt } |
                     element summary:sent { xsd:unsignedInt }
                 ) &
+                (
+                    attribute sync { xsd:boolean } |
+                    element summary:sync { xsd:boolean }
+                ) &
 # Units is seconds
                 (
                     attribute maxError { xsd:float } |
@@ -287,19 +142,20 @@
                     attribute max_delay { xsd:float } |
                     element summary:max_delay { xsd:float }
                 )? &
-# Not sure what definition you are using... Leaving out for now.
-#                (
-#                    attribute min_ipdv { xsd:float } |
-#                    element summary:min_ipdv { xsd:float }
-#                )? &
-#                (
-#                    attribute med_ipdv { xsd:float } |
-#                    element summary:med_ipdv { xsd:float }
-#                )? &
-#                (
-#                    attribute max_ipdv { xsd:float } |
-#                    element summary:max_ipdv { xsd:float }
-#                )? &
+# *_ipdv_jitter definitions from RFC 3393 (Section 4.5)
+# Basically, consecutive packets are selected for computing ipdv.
+                (
+                    attribute min_ipdv_jitter { xsd:float } |
+                    element summary:min_ipdv_jitter { xsd:float }
+                )? &
+                (
+                    attribute med_ipdv_jitter { xsd:float } |
+                    element summary:med_ipdv_jitter { xsd:float }
+                )? &
+                (
+                    attribute max_ipdv_jitter { xsd:float } |
+                    element summary:max_ipdv_jitter { xsd:float }
+                )? &
                 element summary:value_buckets {
                     element summary:value_bucket {
                         attribute value { xsd:float } &
@@ -322,4 +178,3 @@
 
  
         }
-