Subject: RE: Open issue 15: chunk with a too short length

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 23 Dec 2005 13:40:02 +0100

Dear Benoit, all,
 
Why don't we make the chunk elements by default variable length and just
don't allow them to be fixed length??
 
Regards,
 
Thomas

--
Thomas Dietz                       E-mail: [email-masked]
Network Laboratories               Phone:  +49 6221 90511-28
NEC Europe Ltd.                    Fax:    +49 6221 90511-55
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
<http://www.netlab.nec.de/> 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Benoit Claise
Sent: Wednesday, December 21, 2005 11:55 PM
To: Benoit Claise
Cc: psamp
Subject: Re: Open issue 15: chunk with a too short length

BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
ipPayloadPacketSection information element descriptions currently contain:

"If insufficient octets are available,
the remainder of the data should be zero-filled and an additional
information element sent (e.g., ipPayloadLength) indicating how
much of the data is valid."

Obviously these sentences will have to be removed.

Regards, Benoit.

Dear all,

>From the Vancouver meeting minutes:

Open Issue (not numbered): Chunk with too short length
How to encode "chunk" with a too short length? Padding wouldn't be
recognized 
by the collector. One solution would be using a new template for each
length.
Proposal: The protocol draft should say that padding MUST NOT be used for
variable length IEs.

Here is a new proposed text (actually, only the second paragraph is new)

Basic Packet Report

For each selected packet, the Packet Report MUST contain the following
information: 
- The associationsId Information Element 
- Some number of contiguous bytes from the start of the packet, including
the packet header (which includes link layer, network layer and other
encapsulation headers) and some subsequent bytes of the packet payload.
Alternatively, the number of contiguous bytes may start at the beginning of
the payload. The Layer2PacketSection, l2PayloadPacketSection,
mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and
ipPayloadPacketSection PSAMP Information Elements are available for this
use.  
- The input sequence number(s) of any Selectors that acted on the packet,
represented by the selectorInputSequenceNumber Information Element. 
  
The contiguous Information Elements (Layer2PacketSection,
l2PayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection,
ipPacketSection, and ipPayloadPacketSection) MAY be encoded with a fixed
length field or with a variable sized field. If one of these Information
Elements is encoded with a fixed length field whose length is too long for
the number of contiguous bytes in the selected packet, padding MUST NOT be
used. In this case, the Exporting Process MUST export the information either
in a new Template Record with the correct fixed length field, or either in a
new Template Record with a variable length field.  

Feedback?

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Dec 2005 14:06:50 +0100

Dear Thomas,
> Dear Benoit, all,
>  
> Why don't we make the chunk elements by default variable length and 
> just don't allow them to be fixed length??
I see a drawback with this approach. I have to specify in [PSAMP-PROTO] 
that all chunk elements will be encoded with variable length I.E.. Fine, 
I can list all the ones that exist today. But what about the new ones, 
administered by IANA. How do we know that these are chunk elements or 
not? We could say: if it contains "Section" part of the name, this is a 
chunk, so encoded with a variable length -> this is a little bit light! 
Alternatively, we could specify in the I.E. description that it must be 
encoded with a variable length but it break the independence of the 
information model versus the protocol.

Regards, Benoit.
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Benoit Claise
>     *Sent:* Wednesday, December 21, 2005 11:55 PM
>     *To:* Benoit Claise
>     *Cc:* psamp
>     *Subject:* Re: Open issue 15: chunk with a too short length
>
>>         How to encode "chunk" with a too short length? Padding
>>         wouldn't be recognized
>>         by the collector. One solution would be using a new template
>>         for each length.
>>     For each selected packet, the Packet Report MUST contain the
>>     following information:
>>     - Some number of contiguous bytes from the start of the packet,
>>     including the packet header (which includes link layer, network
>>     layer and other encapsulation headers) and some subsequent bytes
>>     of the packet payload.  Alternatively, the number of contiguous
>>     bytes may start at the beginning of the payload. The
>>     Layer2PacketSection, l2PayloadPacketSection,
>>     mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection,
>>     and ipPayloadPacketSection PSAMP Information Elements are
>>     available for this use. 
>>     - The input sequence number(s) of any Selectors that acted on the
>>     packet, represented by the selectorInputSequenceNumber
>>     Information Element.
>>      
>>     l2PayloadPacketSection, mplsLabelStackSection,
>>     mplsPayloadPacketSection, ipPacketSection, and
>>     ipPayloadPacketSection) MAY be encoded with a fixed length field
>>     or with a variable sized field. If one of these Information
>>     Elements is encoded with a fixed length field whose length is too
>>     long for the number of contiguous bytes in the selected packet,
>>     padding MUST NOT be used. In this case, the Exporting Process
>>     MUST export the information either in a new Template Record with
>>     the correct fixed length field, or either in a new Template
>>     Record with a variable length field.  
>>
>>
>>     Feedback?
>>
>>     Regards, Benoit.
>>
>

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 23 Dec 2005 15:26:43 +0000

> don't allow them to be fixed length??

I think in many cases the chunks will be sufficiently small to mean that
they are guaranteed to be complete.  i.e. a ipv4HeaderSection of 20 bytes.
Forcing a variable length field in this case will give more overhead than
necessary.

I think most sensible implementations will use a variable length for large
chunks in IPFIX, but specifying how to do it using templates gives a clear
direction to anyone implementing a dual IPFIX / NetFlow v9 exporter.

Andrew

>>     packet, represented by the selectorInputSequenceNumber Information
>>     Element.
>>      
>>     padding MUST NOT be used. In this case, the Exporting Process MUST
>>     export the information either in a new Template Record with the
>>     correct fixed length field, or either in a new Template Record
>>     with a variable length field.  
>>
>>
>>     Feedback?
>>
>>     Regards, Benoit.
>>
> 

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