duffield@research.att.com wrote:
Derek, Jennifer,
See comments inline below:
________________________________________
From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On Behalf
Of Derek Chiou
Sent: Monday, November 15, 2004 3:29 AM
To: Rexford,Jennifer L (Jennifer)
Cc: psamp@ops.ietf.org
Subject: Re: comments on draft-ietf-psamp-framework-09.txt
Hi Jennifer,
Jennifer Rexford wrote:
- page 13-14: Under "content-dependent sampling" or "non-uniform
probabilistic sampling," it may be helpful to include "sampling
packets in proportion to their length" as an example.
Doesn't "sampling packets in proportion to their length" fall into the
content _independent_ sampling? If you sample periodically by time,
you'll get sampling of packets in proportion to their length.
I was trying to think of a meaningful example to make it more clear
why content dependent sampling would be useful. The one thing that
came to mind was sampling on the packet-length field in the IP header.
That said, you are right that there are content-independent ways to
sample this way, too, so perhaps it isn't a good choice for an example.
In any case, I think including an example might be helpful here.
An example is reasonable. A forward pointer to trajectory sampling might
work?
Another example is "sampling packets with a probability dependent on application type as indicated by TCP/UDP port number". I propose to use this example rather than include a discussion about different ways to do packet length proportional sampling. Or perhaps people want a discussion on the shortcomings of using port numbers to attribute applications type....
You could say "sampling packets with a probability dependent on a
TCP/UDP port number" and not mention the mapping to application.
Trajectory sampling is treated as filter (i.e. deterministic selection according to packet content) so it not an example here.
"However, if prior selection not based on routing state has reduced the
packet stream to below line rate, subselection based on routing state
may be feasible."
Easier to parse, though still a little confusing. How could the packet
stream on the line be above line rate? (Or, are you talking about the
packets before they go into the output queue? Or, is the "line rate"
the bandwidth allocated for psamp records? Is the idea that subselecting
routing state [such as the prefix entry that matched the packet?] is
not reasonable unless the sampled stream is low-rate enough to enable
the look-ups to take place? But, isn't the lookup already done as part
of regular packet handling? Hmmm, I think I still don't quite understand
what the sentence is driving at.)
Yes, if the PSAMP selector is embedded in a router, that router should be
able to access routing state at line rate. However, the PSAMP selector
may not be implemented in the fast path that is able to access routing
state at line rate. It could be implemented as another stage in the fast
path that does not have line-rate access to routing state or in the slow
path that cannot access routing state at line-rate.
However, if there are selectors that first reduce the packet stream to a
more manageable rate (somewhere under line rate), it's possible that the
slow path selector could select based on routing state.
I think that's what this sentence is trying to say.
How about:
Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access routing state at line rate. However, when filtering follows sampling in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently slow that the filter could select based on routing state.
Looks good to me.
Derek
Thanks!
-- Jen
Nick
|