Subject: [bmwg] bmwg-mcastm-08.txt: *capsulation methodologies

From: Kevin Dubray <[email-masked]>
Date: Wed, 25 Sep 2002 16:49:11 -0400

Kevin Dubray wrote:

  > Lastly, when RFC 2432 was put out, DVMRP was the driver for
  > the encapsulation related metrics. It appears that folks
  > employ other tunneling mechanisms (e.g., GRE, MPLS) to carry
  > their multicast through the unicast world. Do folks agree
  > that the level of detail stated in sections 4.4.1 - 4.4.3 is
  > adequate?

OK.  Let's see if I can crisp up my concerns.  They center around:
1) traffic rates, 2) test topology, and 3) reporting specifications
for the encapsulation, decapsulation, and re-encapsulation throughput
methodologies.

First, in the throughput methodologies, there's generally
symmetry regarding packet size as to what's offered to the DUT
and what's measured from the DUT. For example, 64 byte packets in,
64 byte packets out.

If one is measuring, say, the encapsulation throughput of GRE wrapped
multicast packets, an encapsulated output packet is 24 bytes larger
(presuming, of course, same transport medium). So, while you can count 
packets in-to-out to determine loss for some collection window, the 
outbound link maybe oversubscribed wrt to Oload at the higher end of
the medium's capacity.  This consideration should be reflected in
the metric's procedure.

IMO, the methodology leans too much on RFC 2544 for its specification. 
Shouldn't *capsulation throughput methodologies be aligned more with
multicast-oriented throughput methodologies?

Secondly, I'm assuming the decapsulation test topology conforms to
figure 1 in section 3(?). (Single DUT: 1 ingress port to many
egress ports).  Is this topology necessary for the encapsulation
throughput case? Or would a 1 ingress port to 1 egress port config
work?  What's the constitution of traffic for encapsulation
throughput? (E.g., single group class destined for a single tunnel
on a single egress interface or multiple group classes over a
single ingress interface destined to multiple tunnels over
multiple egress interfaces?)  Note that I'm not advocating that we
specify all the combinations of the possible configurations.
But I'd like us to specify a representative config that would provide
behavioral insight.

Lastly, as the above discussion suggests, there are lots of
variables in these tests. I think the current reporting
requirements must be strengthened to capture the key components.

Again, we're just relying too much on 2544 for these metrics' 
methodologies.

-Kevin

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg