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

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 24 May 2007 14:54:24 +0100

Gerhard, Benoit,

>>
>> Apparently, my assumption was right:
>> There are no good reasons at all for sending all Templates over the same
>> stream 0, as specified in ipfix-protocol.
>>   
> You got it right in your initial email: "is a relict from very early 
> days of PR-SCTP when reliability options were assumed to be a per-stream 
> setting"
>
...

>> This may explain why nobody recognized the uselessness
>> of this detail in the IPFIX protocol specs earlier.
>> 

We did recognize it during last interop event and we were sure about it after discussing the current SCTP section of the guidelines with the SCTP people (during last IETF meeting and before the last IPFIX meeting). Actually this was one of the triggers to write the current SCTP section of the guidelines, trying to clarify the use of SCTP  (e.g. per-message (partial) reliability, multiple streams, unordered delivery). But the protocol had already gone through IESG review and we couldn't change it nor contradict it. The constraint of sending templates on stream 0 had to be kept.

I see a big danger in trying to change it now, with a new document. Not because the basic idea is bad, on the contrary, we basically proposed the same (even if we had the constraint, imposed by the protocol, to send templates on stream 0) but exactly because it apparently contradicts what has been specified in the protocol and recommended in the guidelines (which have to be consistent with the protocol).
This can only generate confusion among the implementers. 

Regards,
Elisa

> Yep.
>> Instead of standardizing something useless now and waiting for an
>> improvement later, I suggest the following quite small changes:
>>
>> 1. Remove the stream 0 related parts from the protocol draft, thus
>> avoiding to specify something useless or confusing.
>>   
> The latest draft mentions "Template Sets and Option Template Sets SHOULD 
> be sent on the SCTP stream zero"
> It was a MUST in [IPFIX-PROTO] in the past, and was changed.
>  >From RFC2119
> 
>     3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>        may exist valid reasons in particular circumstances to ignore a
>        particular item, but the full implications must be understood and
>        carefully weighed before choosing a different course.
>       
> 
> So it is really a big problem?
> 
>> 2. Incorporate draft-claise-ipfix-export-per-sctp-stream-00 as
>> recommendations into the implementation guidelines.
>>   
> IMHO, there is still one piece missing in the picture.
> Sending one template per stream is useful but how do you know how many 
> streams you need when you start up the SCTP association?
> What if you need more streams, and don't want to shut down the SCTP 
> association to increase the number?
> This is what I meant by "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"
> 
> Regards, Benoit.
>> Regards,
>> Gerhard
>>
>>
>> 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] <mailto:[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 16:38:14 +0200

Elisa,

Boschi, Elisa wrote:
> I see a big danger in trying to change it now, with a new document. Not
> because the basic idea is bad, on the contrary, we basically proposed
> the same (even if we had the constraint, imposed by the protocol, to
> send templates on stream 0) but exactly because it apparently
> contradicts what has been specified in the protocol and recommended in
> the guidelines (which have to be consistent with the protocol).

If the IPFIX protocol specs cannot be changed any more (although this is
 annoying in my opinion), the best thing we can do is to tackle this
issue in a new I-D as now initiated by Benoit. After all, the purpose is
not to confuse implementers, but to enable an efficient deployment of
IPFIX over SCTP and PR-SCTP.

IMHO, we should not refrain from improving obvious deficiency of the
IPFIX protocol just because something is written in the implementation
guidelines ;)

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
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 24 May 2007 16:38:14 +0200

Elisa,

Regards,
Gerhard