Subject: Re: [IPFIX] Implementation Guidelines // SCTP

From: "Boschi, Elisa" <[email-masked]>
Date: Wed, 23 May 2007 17:29:49 +0100

Benoit, Gerhard,

I'd invite you both at having a look at the current version of 
the Guidelines before proposing to add something wich has been 
already addressed.

Also I have a problem in understanding what exactly you're trying to 
patent or where the new idea is. Is it as you say in your -00 draft 
(dated 30th April 2007) in section 4:

"Each (Options) Template and its associated Data Records would be
 sent on a unique SCTP stream. The (Options) Template would still
 be sent reliably, while the level of reliability for the Data
 Records would be chosen depending on the specific application." 

Please note than that draft-ietf-implementation-guidelines-00.txt, 
section 7.1 (SCTP), paragraph 5 said:

"A more complex device might allocate one data stream per Template
 ID, so that data pertaining to each Template ID is transferred quite
 independently."

and this has been published on the * 30th of August 2006 * !! 
(almost 9 months ago!)

The current version of the Guidelines (I refer to -03 published on the 
26th of April, even if -04 has been submitted today) specifies:

   "An SCTP association may contain multiple streams.  SCTP associations
   used to transport IPFIX Messages MUST contain at least two streams.
   Messages containing Templates Sets and Options Template Sets, and
   Template Withdraw Messages, SHOULD be sent on stream 0.  Messages
   containing Data Sets SHOULD be sent on SCTP streams other than stream
   0.  This implies that, at minimum, stream 0 is used for Templates and
   stream 1 is used for Data Sets.

   The Collecting Process MUST be able to process any Message received
   on any stream.

   Multiple SCTP streams are useful for avoiding head-of-line blocking,
   thereby minimising end to end delay from the Exporting Process to the
   Collecting Process.  Example applications for this feature would be
   using one SCTP stream per Observation Domain, one stream per type of
   data (or Template ID), or one stream for flow data and one for
   metadata."

The only reason we're keeping the recommendation to use stream 0 for 
templates is that it is specified in the IPFIX protocol, which at this 
point cannot be changed.

Regards,
Elisa

P.S.: PR-SCTP implementations have been tested in both the second 
interoperability event held in Salzburg and in the last one held 
in Berlin. The implementations used two streams, one (Stream 0) 
to transmit templates and the other one for data, exactly as 
specified in the protocol.

Benoit Claise wrote:
> Gerhard, all,
> 
> What you're proposing is something that Cisco has been thinking about 
> for more than 6 months now.
> Actually we filled in a patent on that one. Because you proposed the 
> idea, we worked on the creation of a new draft
> http://www.ietf.org/internet-drafts/draft-claise-ipfix-export-per-sctp-stream-00.txt 
> fully explaining the idea
> We also posted an IPR: see 
> https://datatracker.ietf.org/public/ipr_list.cgi.
> The title of the IPR disclosure is "Cisco's Statement about IPR claimed 
> in draft-claise-ipfix-export-per-sctp-stream-00.txt."
> Alternatively, directly look up 
> http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt
> 
> I didn't want to answer this email before the draft and the IPR were 
> posted.
> 
> Note that a new version of this draft will follow, with the 
> functionality to add streams in SCTP, when available in the SCTP reset 
> draft 
> (http://www.ietf.org/internet-drafts/draft-stewart-sctpstrrst-04.txt).
> Once done, my personal view is that it would be a good candidate for the 
> new charter discussion in Chicago
> 
> Regards, Benoit.
>> Hi Elisa, Benoit,
>>
>> Boschi, Elisa wrote:
>>   
>>>> 6.1:
>>>> The citation from protocol-24 has changed !!! Now it is:
>>>>
>>>>    Template Sets and Option Template Sets SHOULD be sent on the SCTP
>>>>    stream zero. Template Sets and Option Template Sets MUST be sent
>>>>    reliably.
>>>>
>>>> I propose to emphasize more on this important implementation aspect since
>>>> the reliable transport of Templates is one of the main advantages of SCTP!
>>>> There is a side-effect:
>>>>    "A simple system might use just one data stream for all the exported
>>>>    data."
>>>> This implies that the all IPFIX messages are sent over one reliable
>>>>       
>>> stream!
>>>     
>>> 6.1 has changed quite a bit and the new version should address your
>>> concerns... more about this in the next days
>>>     
>>
>> What is the reason for separating Templates from the corresponding Data
>> Sets and for sending them over a separate stream (zero)?
>>
>> I've been talking to Michael Tüxen, who was working on PR-SCTP. It seems
>> that the sentence
>>
>>     Template Sets and Option Template Sets SHOULD be sent on the SCTP
>>     stream zero.
>>
>> from the protocol draft is a relict from very early days of PR-SCTP when
>> reliability options were assumed to be a per-stream setting. Actually,
>> it is a per-message property, i.e. in the same stream, one message can
>> be sent fully reliable and another one partially reliable. The effect of
>> a stream is that the message order is preserved and that head-of-line
>> blocking at the receiver does not exist between different streams.
>>
>> Therefore, it seems to be more appropriate to have a separate stream for
>> each Template, and to send the Template as well as the corresponding
>> Data Sets over this stream. This ensures that the Template arrives
>> before the Data Sets. Templates would be sent in reliable messages, Data
>> Sets in partially reliable messages.
>>
>> Am I missing the point here?
>>
>> Regards,
>> Gerhard
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipfix
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 24 May 2007 09:20:49 +0200

Elisa, all,

Please find my comments inline.

> the Guidelines before proposing to add something wich has been

Don't worry, I did have a look before writing my last e-mail :)

>  Records would be chosen depending on the specific application."

Exactly, and this is the obvious and effective way to use PR-SCTP as
transport protocol for IPFIX.

On the other hand, until now, nobody could explain me the reason for the
"SHOULD" in the protocol draft related to sending all Templates over
stream 0. There is no reason to standardize this restriction. It even
disadvices and disallows the effective usage of PR-SCTP as described in
the -00 draft and pointed out in my e-mail from two months ago.

> and this has been published on the * 30th of August 2006 * !!

As I understand this remark, it refers to data only. However, this
discussion is about the Templates which are most effectivly sent over
the same stream as the associated records in a reliable message.

> templates is that it is specified in the IPFIX protocol, which at this

Yes, I am aware of the dependency between the two drafts. And I know
that you cannot recommend something in the guidelines which is against
the protocol specification.

I'm sorry that I did not come up with this issue earlier, but we only
recently started to implement SCTP support for our probe. And this also
was the first time when I tried to understand how PR-SCTP actually
functions.

> specified in the protocol.

I asked Lutz Mark after the last interop in November 2006 if PR-SCTP was
tested, and he answered that this was not the case because IPFIX over
PR-SCTP was not implemented. But maybe this was a misunderstanding?

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 24 May 2007 09:20:49 +0200

Elisa, all,

Regards,
Gerhard

---

From: Lutz Mark <[email-masked]>
Date: Thu, 24 May 2007 13:57:53 +0200

Gerhard and Elisa,

> PR-SCTP was not implemented. But maybe this was a misunderstanding?

maybe I can clarify this.

I gather that we have tested IPFIX over SCTP (not PR-SCTP) on all
IPFIX Interop Events. There were one collector implementation
that expected IPFIX templates on stream 0.
On the last event in Berlin we have also tested IPFIX
interoperability when the Exporter uses multiple
SCTP streams (but no PR-SCTP).

Regards,
Lutz

---

From: Lutz Mark <[email-masked]>
Date: Thu, 24 May 2007 13:57:53 +0200

Gerhard and Elisa,

Regards,
Lutz

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 May 2007 10:23:58 -0400

Lutz and all,

To clarify a bit further: the point may be a minor one, but we did test
IPFIX over PR-SCTP, meaning "an SCTP stack implementing the partial
reliability extension" as we generally do throughout the IPFIX
documents, though all the tests we ran used fully reliable delivery for
all messages (i.e. the lifetime of each message was effectively
infinite, in the parlance of the KAME SCTP API). Partially reliable
delivery is difficult to test in the environment we had set up (a local
LAN) and was not considered a priority compared to basic SCTP operation
and SSL/TLS over TCP.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 24 May 2007 10:23:58 -0400

Lutz and all,

Regards,

Brian