Subject: Re: [ipfix] export packet length

From: [email-masked]
Date: Thu, 01 May 2003 11:21:56 -0400

Since the only thing mandated for the transport is congestion awareness 
it would seems to make sense to have a length field in the IPFIX
protocol.

I don't like the idea of having different formats based on the
transport (someone mentioned that as an option). A 2 byte length
field seems a small price to pay or better transport independance.

Paul

> Reinaldo Penno wrote:
> 
> That's a good idea.
> 
> Other protocols like HTTP and SIP make it mandatory to include the
> Content-Length header (which tell the length of the payload) when
> carried over TCP. It helps a lot when dealing with fragmentation.
> 
> Regards,
> 
> > -----Original Message-----
> > From: Maurizio Molina [mailto:[email-masked]]
> > Sent: Friday, April 25, 2003 11:50 AM
> > To: [email-masked]
> > Subject: [ipfix] export packet length
> >
> >
> > Hi all,
> > I hope not to rise an issue already discussed in the WG. If
> > yes, I apologise in advance. If an IPFIX export packet is
> > carried over TCP, it's not unusual that it gets split across
> > multiple TCP segments. At the collector side, on the
> > contrary, the implementation of the parsing is much simpler
> > if only full export packet are parsed. If the information
> > about the WHOLE export packet were contained in the header,
> > it would be simple to wait until all the bytes composing an
> > export packets are read from the TCP socket before beginning
> > the parsing. Unfortunately, this information isn't currently
> > contained in  Netflow 9 packet header (I suppose, due to
> > Netflow's 9 "bias" towards UDP...). Therefore, a parsing
> > implementation having to deal with this "fragentation"
> > problem without this information needs to be much more
> > complicated (e.g. getting step by step the lenght of each
> > flow set, see if it's all there, parse it and go on....). In
> > summary: if IPFIX has to be carried over tcp, having the
> > length of the export packet in the packet header would be
> > beneficial. Regards, Maurizio
> >
> >
> > --
> > Maurizio Molina
> > Research Staff member
> > Network Laboratories Heidelberg
> > NEC Europe Ltd.
> > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany.
> > Tel. (49)6221 90511-18 Fax: (49)6221 90511-55
> > e-mail: [email-masked]
> > Web: www.ccrle.nec.de
> >
> >
> >
> > --
> > 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: Juergen Quittek <[email-masked]>
Date: Thu, 01 May 2003 20:05:14 +0200

I agree. These two byte appear to be well spent.

    Juergen

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 02 May 2003 09:41:49 +0100

> field seems a small price to pay or better transport independance.

I agree with this. If we go with two types, we will always have to
take into account the maximum possible size of the object, the
error cases etc.

The one byte overhead seems a small price for the reduction in
complexity.

Stewart