Subject: comments on draft-ietf-psamp-framework-09.txt

From: Jennifer Rexford <[email-masked]>
Date: Sat, 13 Nov 2004 11:34:15 -0500 (EST)

Hi folks,

I just read through the latest draft of "A Framework for Packet
Selection and Reporting" (draft-ietf-psamp-framework-09.txt) and
think the document looks great.  I have just a few minor comments,
and one suggestion for a few sentences of additional text (on the
subject of congestion-aware transport).  More below...

-- Jen

- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency".
Also, the term "non-contingency" seems a bit strange.  The text for
the bullet could add something about why this requirement is included
(e.g., "in order to limit the complexity of the selection logic").

- page 12, Section 4.3: in the bullet on "Congestion Avoidance," it
would be good to include a forward pointer to Section 8.2 where this
issue is discussed further.

- 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.

- page 15: At the end of Section 5.2, I didn't understand the
sentence "However, if selection not based on routing state has
reduced down from line rate...."  I had trouble parsing it.

- page 21: Section 8.2 talks about the need for unreliable,
congestion-aware transport, and shifts in the last paragraph to
talking about IPFIX rather than PSAMP.  I wasn't sure what the the
IPFIX paragraph was trying to get at, and if/how it relates to the way
PSAMP should achieve congestion-aware transport.  Somewhere in the
document (either in 8.2, 8.5, or in 10.2), it would be worth
commenting on lighweight ways to achieve the goal of congestion-aware
transport.  Section 8.2 could end by saying something like
"Congestion-aware transport of PSAMP records could be achieved in
various ways.  For example, the PSAMP device could have an export rate
limit (as discussed in Section 8.5) that is configured by the
controller based on observations of the packet loss rate in delivering
PSAMP records.  This would ensure that the transport rate adapts in
the presence of congestion without requiring the PSAMP device to
receive acknowledgment packets or implement the adaptation algorithm
directly."  I think this is important for conveying how the requirement
of congestion-aware transport can be satisfied without introducing
a lot of complexity in a PSAMP device that much operate at high speed.

- page 32: My room number is A139.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Derek Chiou <[email-masked]>
Date: Sun, 14 Nov 2004 17:47:17 -0500

Some in-lined comments.

>Also, the term "non-contingency" seems a bit strange.  The text for
The term is strange to me as well.  I'm not sure what would be a good 
replacement.  Perhaps Future-Independent?

>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.

>reduced down from line rate...."  I had trouble parsing it.
Is the following more clear?

"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."

---

From: Jennifer Rexford <[email-masked]>
Date: Mon, 15 Nov 2004 00:15:54 -0500 (EST)

> 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.

> packet stream to below line rate, subselection based on routing state

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.)

Thanks!

-- Jen

---

From: Derek Chiou <[email-masked]>
Date: Mon, 15 Nov 2004 03:28:38 -0500

Hi Jennifer,

>In any case, I think including an example might be helpful here.
An example is reasonable.  A forward pointer to trajectory sampling 
might work?

>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.

Derek