Subject: [ipfix-req] Variable Length Fields : was RE: [ipfix-eval] RE: Discussion of C andidate Protocols - data model; broadcast vs reliable

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 10 Oct 2002 11:58:35 -0700

that was a valid question..I was thinking about it myself (not specially in
terms of netflow, tough.)

Although we are concerned with the basic packet fields, it is expected that
variable lenght fields like URLs, SDP headers, HTTP headers, etc will be
widely used. IMHO we should look a little bit down the road in order to
guarantee some lifetime for the protocol without many revisions. 

It seems to me that the requirements doc should provide/ask that the
protocol (data model) must support variable length fields now or be readily
extensible. Maybe some text in section 6.2.

regards,

Reinaldo

> -----Original Message-----
> From: Vamsidhar Valluri [mailto:[email-masked]]
> Sent: Thursday, October 10, 2002 11:26 AM
> To: Peter Ludemann
> Cc: Ganesh Sadasivan; [email-masked]
> Subject: Re: [ipfix-eval] RE: Discussion of Candidate Protocols - data
> model; broadcast vs reliable
> 
> 
> Peter,
>   Please see inline
> 
> On Thu, 10 Oct 2002, Peter Ludemann wrote:
> 
> > Sorry for bringing up the topic of UDP ... I mis-read a 
> thread and thought
> > that UDP was coming back on the table.
> >
> > It is not clear to me how any protocol that does not contain
> > application-level ACKs can be fully reliable, even if 
> layered over TCP or
> > SCTP. This is because the transport-layer acknowledgment 
> only means that the
> > data have arrived at the other machine, not that the application has
> > actually processed it. (There's nothing preventing a TCP or 
> SCTP stack from
> > allowing application-level acknowledgment; but I'm not 
> aware of any for TCP
> > and my reading of the API in RFC 2960 indicates that the 
> acknowledgment is
> > transport-level.)
> >
> > As to my comment about UDP vs TCP for performance ... this 
> is probably
> > irrelevant for the current discussion because the proposal 
> is that IPFIX
> > would use NetFlow over TCP or SCTP. In such a case, a 
> UDP-with-reliability
> > protocol (which NetFlow isn't; but, for example, NFS is) 
> ends up being about
> > the same performance as TCP. Clearly, the path length with 
> pure UDP would be
> > less than for TCP because UDP is just "fire and forget". However, if
> > broadcast is being used to increase reliability (as Ganesh 
> points out, this
> > isn't necessary; but if there is no ACK mechanism, then the 
> only choice is
> > to broadcast to all collectors), then the path length 
> increases. Whether
> > outputting 2 UDP packets is a longer or shorter instruction 
> path length than
> > sending a single TCP packet, I don't know.
> >
> > Slight change of subject: could NetFlow be easily extended 
> to handle data
> > that isn't fixed-length (e.g., HTTP URLs)? I know that in 
> NetFlow's current
> > use, there's no need for such attribute export; but there 
> are smart devices
> > that look deeper into packets for smart switching or 
> firewalling, which can
> > use such information and might want to export it. [Probes 
> can also export
> > such information.]
> >
> 
> 
> Example: If we want to send a variable length field we use 
> repeat count
> 
> 
> Suppose we want to send string "abc"
> 
> Netflow version 9 Template
> 
> <----2 bytes ----->
> ------------------
> header...
> ------------------
> Field 1 Type = REPEAT_COUNT
> ------------------
> Field 1 Length = 2 bytes
> -----------------
> Field 2 Type = CHAR_VARIABLE_LEN
> -----------------
> Field 2 Length = 1 byte
> -----------------
> .......
> 
> Corresponding Netflow version 9 Data record
> 
> <-----2 bytes------>
> -------------------
> Header .....
> -------------------
>    3 = ( Next field (Field 2) is repeated 3 times)
> -------------------
>  a      |   b
> -------------------
>  c      | ......
> -------------------
> 
> -vamsi
> 
> > Time for me to shut up and go on vacation.
> >
> > - peter
> >
> > > -----Original Message-----
> > > From: majordomo listserver 
> [mailto:[email-masked]]On Behalf
> > > Of Ganesh Sadasivan
> > > Sent: Wednesday, October 09, 2002 2:51 PM
> > > To: Peter Ludemann
> > > Cc: [email-masked]
> > > Subject: Re: [ipfix-eval] RE: Discussion of Candidate 
> Protocols - data
> > > model; broadcast vs reliable
> > >
> > >
> > >
> > >
> > > Peter Ludemann wrote:
> > >
> > > > This note discusses two things:
> > > >  - whether we need a data model to define the protocol
> > > >    (I claim that we do not)
> > >
> > > Agreed.
> > >
> > > >
> > > >  - cost of UDP broadcast vs minimalist reliable transport
> > > >    (I claim that there is very little difference)
> > >
> > > What do you mean by "minimalist reliable transport" ?
> > > Since congestion awareness is mandatory, I don't know
> > > why UDP is a topic of discussion here. See my comments inline.
> > >
> > > >
> > > >
> > > > [email-masked] wrote Monday, October 07, 2002 7:35 AM:
> > > >
> > > > > Peter Ludemann wrote:
> > > > [snip]
> > > > > > YES ... so, can we all agree that data model issues are not
> > > > > > part of this discussion?
> > > > >
> > > > >       No. We have no interoperability without a data model.
> > > >
> > > > I agree that we need a data model. I don't see why it 
> should affect the
> > > > discussion of the export protocol. The only 
> requirements on the export
> > > > protocol are that it exhibit the desired reliability 
> and efficiency; and
> > > > that it be able to transport all the data types required by the
> > > data models.
> > > > If we can agree on all the data types, then we can define the
> > > protocol; this
> > > > does not require defining the entire data model.
> > > >
> > > > [After all, SNMP is defined independently of the 
> various MIBs - which
> > > > correspond to the data model]
> > > >
> > > > >       No. Generalized data movers are not the problem.
> > > > >       Defining a protocol that is well defined enough so
> > > > >       that many device vendors can export data and many
> > > > >       application vendors can process the data regardless
> > > > >       of the device is problematic if all you define is a
> > > > >       general purpose data mover.
> > > >
> > > > But deciding on an adequate "generalized data mover" is the
> > > point of this
> > > > evaluation process, I thought. I expect that there will 
> be multiple data
> > > > models, for the various kinds of generalized devices. (e.g.,
> > > for our probe,
> > > > we've defined three generic groupings of data: volume metrics;
> > > QoS metrics;
> > > > usage metrics and attributes -- similarly, SNMP's 
> enterprise MIBs and
> > > > RADIUS's vendor-specific attributes).
> > > >
> > > > There is one place where the nature of the data might 
> intersect with the
> > > > protocol -- the high-volume metrics such as exported by
> > > NetFlow; and where
> > > > the claim is that a reliable protocol is an unnecessary
> > > overhead. So, let me
> > > > discuss this a bit more.
> > > >
> > > > The argument is that with high volume export it is 
> preferable to do
> > > > multi-cast UDP with sequence numbers; data loss can be detected
> > > by noting
> > > > which sequence numbers are missing ... and reliability can be
> > > increased by
> > > > having multiple receivers and de-duplicating what they receive.
> > >
> > > One does not need to multicast UDP to indicate missing 
> reliability.
> > >
> > > >
> > > >
> > > > For such a situation, the reliable protocol's 
> *implementation* would not
> > > > keep a queue of data to retransmit on fail-over; it would only
> > > keep enough
> > > > buffer to deal with TCP's or SCTP's flow control and to 
> handle bursts of
> > > > records. ACKs would be used only to notice when data are not
> > > received at the
> > > > other end and to cause fail-over. TCP "write would 
> block" also causes
> > > > fail-over.
> > >
> > > So records can be lost in both cases. Also in a continuous export
> > > (in the case of
> > >
> > > high volume export) the rate of ACKs is once every 2 send packets.
> > >
> > > >
> > > >
> > > > I would argue that the cost of exporting this way is very
> > > similar to that of
> > > > the UDP broadcast.
> > >
> > > Are you talking w.r.t the end-point (exporter & collector) or the
> > > network itself.
> > >
> > > For the former, the processing overhead is much higher in TCP.
> > >
> > > > And on the receiving end, it is *much* easier to handle
> > > > than a UDP-broadcast, which also needs stronger 
> hardware because of the
> > > > higher de-duplication load.
> > > >
> > > > Can be about the same for both:
> > > > - data copying (if scatter/gather is used)
> > > > - protocol overhead (sequence number, template ID, etc.)
> > >
> > > In a typical datapath the instruction ration of UDP to TCP is
> > > multi-fold. I don't know how you can tell that the protocol
> > > overhead is the same.
> > >
> > > >
> > > >
> > > > The possible extra cost of the "reliable" export version is:
> > > > - timer for noticing when ACK isn't received [trivial cost]
> > > > - TCP vs UDP (little difference with modern implementations)
> > > > - TCP retransmit with packet loss (typically very low)
> > > > - cost of fail-over when no ACK received or write would block
> > > >
> > > > The savings and benefits of the "reliable" version are:
> > > > - fewer packet writes (broadcast requires 2x as many packets;
> > > >   and TCP can pack more efficiently because records can
> > > >   span packets)
> > >
> > > As mentioned above if the  absence of reliability is what we want,
> > > then we need not do a UDP broadcast.
> > >
> > > >
> > > > - lower network traffic (which adds to reliability)
> > >
> > > >
> > > > - smaller machines for receiving
> > >
> > > what does this mean?
> > > thanks
> > > Ganesh
> > >
> > > >
> > > > - more accurate estimate of loss due to lack of reliability
> > > > - can handle congestion
> > > >
> > > > [As an aside, even with the UDP-broadcast version, the 
> exporter ought to
> > > > compute totals for the various metrics and output those from
> > > time to time,
> > > > to provide a more accurate understanding of data loss. Perhaps
> > > such totals
> > > > are already available in the MIBs, but there remains 
> the issue of how to
> > > > correlate with the sequence numbers of the exported data.]
> > > >
> > > > - peter
> > > >
> > > > --
> > > > Help        mailto:[email-masked] and say "help"
> > > in message body
> > > > Unsubscribe mailto:[email-masked] and say
> > > > "unsubscribe ipfix" in message body
> > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > >
> > >
> > > --
> > > Help        mailto:[email-masked] and say "help" in
> > > message body
> > > Unsubscribe mailto:[email-masked] and say
> > > "unsubscribe ipfix" in message body
> > > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> >
> > --
> > Help        mailto:[email-masked] and say 
> "help" in message body
> > Unsubscribe mailto:[email-masked] and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
> 
> 
> --
> Help        mailto:[email-masked] and say "help" 
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 10 Oct 2002 16:10:51 -0700

another one...what happens when a variable lenght field cannot fit in a
single transport packet? And if there are packet drops? One thing is loose
the whole flow record another is to get part of it and probably incorrect
data if it cannot be determined that that flow record has two parts.

-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH] 
Sent: Thursday, October 10, 2002 11:59 AM
To: Vamsidhar Valluri; Peter Ludemann; [email-masked]
Cc: Ganesh Sadasivan; [email-masked]
Subject: Variable Length Fields : was RE: [ipfix-eval] RE: Discussion of C
andidate Protocols - data model; broadcast vs reliable 

regards, 
Reinaldo

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 10 Oct 2002 16:10:51 -0700

-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH] 
Sent: Thursday, October 10, 2002 11:59 AM
To: Vamsidhar Valluri; Peter Ludemann; [email-masked]
Cc: Ganesh Sadasivan; [email-masked]
Subject: Variable Length Fields : was RE: [ipfix-eval] RE: Discussion of C

regards, 
Reinaldo