Re: some doubts

[Nick Duffield <duffield@research.att.com>]

Senthil,

"Ayyasamy, Senthilkumar (UMKC-Student)" wrote:
> 
> Dr.Nick,
> Look for more doubts inline and at the end.
> 
> > 1.The darft also doesnt talk about the transport negotiation which is very important for remote packet sampling .
> >I'm not sure that transport needs to be negotiated as part of the
> >protocol. A more lightweight approach is to have transport parameters
> >in a MIB that can be configured using SNMP. This is attractive because
> >there's already lots of experience with SNMP, it's reliable and allows
> >authentication, and it's easy to create lightweight SNMP clients on a
> >collector.
> 
> reliability ok...but when it comes to transport..congestion & sequence etc comes
> into picture right ? ..So there should be a better way than this approach.

I'm not sure what your focus is here. My picture is the MIB just
specifies
how data is exported, including selecting from amongst those transports
that
PSAMP decides can be used. In the framework document we haven't pinned
the
options down, but PSAMP will have to consider questions like the ones
I think you are raising: should available transport be congestion
avoiding, 
how is sequence numbering done, etc.

> 
> > 6.I presume explicit mentioning of MPLS FEC's  in unnessary.MPLS and ITE WG does that work and are standartizing the characterization.The group can focus on IP flows .
> > Disagree. Knowing the FEC can have useful diagnostic value. Also,
> >remember
> >that we don't propose that PSAMP report flows (in the IPFIX sense), just
> >packet level information.
> You did not get my question.MPLS can be considered as layer 2 or layer 3.
> My view is always *MPLS as a link layer*.If we are interested in lower
> layer details in the packet level may be MAC addresses,VC for frame relay..
> then consider MPLS ..Treat MPLS as one of the many types of packets than
> explicitly mentioning them.The explicit mentioning will be more relevant when
> it is considered in a coarse granular (i.e flow) sense.

I see your question now. Lower level identifiers could be included when
available. When PSAMP gets down to details, we'd have to enumerate the
possibilities and design appropriate reporting formats.

> 
> I have some more clarifications .
> 
> 1.The draft says *Each sampler will be individually configurable to sample packets
>    with a certain probability p.  Examples are probabilistic sampling,
>    in which each packet is selected quasirandomly with probability p,
>    and deterministic sampling, in which packets are sampled
>    periodically with period 1/p. *
> I view the above contention as uniform sampling(correct me if i am wrong).

Yes, uniform sampling.

> We are aware that heavy tailed packtes are prevalent in today's
> traffic.Hence,will the uniform sampling answer these packets ?.

The individual packet sizes do not have a heavy-tailed distribution,
so uniform sampling is OK here. 

(In distinction, flow sizes - measured in bytes or packets - *do* have 
a heavy tailed distribution, which makes them a bad candidate for
uniform
sampling. A better sampling method for completed flow statistics is
proposed 
at http://www.research.att.com/projects/flowsamp/. But this is
not an issue for PSAMP since we do not form flow statistics).

> 
> 2.what will be the exact reaction of collector and exporter in times of overload ?

To be determined. There's a current discussion in IPFIX that may
illuminate this...

Nick

> 
> Thanks in advance ,
> Senthil.
> 
> 
>

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