Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt

From: Tobias Limmer <[email-masked]>
Date: Tue, 3 Nov 2009 20:38:30 +0100

Hi Benoit, all,

I've also got a few comments on the draft ipfix-export-per-sctp- 
stream-04:

2.3. Limitations:
"This method requires multiple SCTP streams in the association between  
the Exporting and Collecting Process, ideally one per Template."

No - if we had only one Template in the association, we would not need  
multiple SCTP streams.

3.1.1. IPFIX Protocol Specifications Limitation:
"Note that a workaround allowed by the IPFIX specifications [RFC5101]  
is to use only one Template Record per SCTP Transport Session, at the  
cost of multiplying the number of SCTP Transport Sessions when  
multiple Template Records are required."

This paragraph sounds a little misplaced, as it already mentions the  
performance impact. After reading it, I was wondering what other  
method would be proposed in this draft.

4.2. Template Management:
"Any Data Sets associated with a Template Record MUST be sent on the  
same SCTP stream on which the Template Record was sent."

According to rfc5101, an Options Template Record is a Template Record.  
Later in the same section you specify: "When the Options Template and  
associated Data Records are sent in different SCTP streams, [...]".
Isn't this a contradiction, or am I missing something here?

4.5. The Collecting Process's Side:
"3. A Data Record is received unreliably although it is expected to be  
sent reliably (due to a previously received Data Record associated  
with the Data Record Reliability Options Template)."

Is it possible for the receiving side of a SCTP connection to  
determine which SCTP messages were sent unreliably? I did not find any  
indication of that in rfc3758. The receiving side only knows if  
complete messages or fragments are skipped.

4.5. The Collecting Process's Side:
"In the case where the Exporting Process does not support the [...]"

This paragraph is a duplicate.

6. Examples:
In Figure 3, you seem to use the Options Reliability Template 257  
(defined in Figure 1) that was received in another stream. A small  
remark would be good which indicates, that all streams belong to the  
same SCTP association.

Thanks,
Tobi

--
Dipl.-Inf. Tobias Limmer
Chair for Computer Networks and Communication Systems
Universität Erlangen-Nürnberg
Martensstr. 3, D-91058 Erlangen, Germany
Phone: +49-9131-8527931  Fax: +49-9131-8527409
eMail: limmer .at. informatik.uni-erlangen.de
URL:   http://www7.informatik.uni-erlangen.de/~limmer

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 04 Nov 2009 09:55:59 +0100

Hi Tobias,

Thanks for your comments. Some replies inline.

> No - if we had only one Template in the association, we would not need  

Indeed, this formulation can be relaxed a little bit.

> method would be proposed in this draft.

Not sure if you got the paragraph right. It talks about SCTP Transport 
Sessions, not SCTP streams. Using different Transport Sessions requires 
indeed much more overhead (e.g., multiple sockets) than just having 
multiple streams in one Transport Session.

> Isn't this a contradiction, or am I missing something here?

This is a flaw of IPFIX terminology.

In the text, we tried to consistently use "(Options) Template" if we 
talk about both Options and non-Options Templates. The sentence above is 
just about non-Options Templates.

Not sure, how we can make this more comprehensible. Maybe a note in the 
terminology section?

> complete messages or fragments are skipped.

I think you are right. We need to check.

Regards,
Gerhard

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

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Tobias Limmer <[email-masked]>
Date: Wed, 4 Nov 2009 10:52:06 +0100

Hi Gerhard,

comments inline!

On 04.11.2009, at 09:55, Gerhard Muenz wrote:
>> "Note that a workaround allowed by the IPFIX specifications  
>> [RFC5101]  is to use only one Template Record per SCTP Transport  
>> Session, at the  cost of multiplying the number of SCTP Transport  
>> Sessions when  multiple Template Records are required."
>> This paragraph sounds a little misplaced, as it already mentions  
>> the  performance impact. After reading it, I was wondering what  
>> other  method would be proposed in this draft.
>
> Not sure if you got the paragraph right. It talks about SCTP  
> Transport Sessions, not SCTP streams. Using different Transport  
> Sessions requires indeed much more overhead (e.g., multiple sockets)  
> than just having multiple streams in one Transport Session.

Oh right, I misunderstood. But then you should always use the term  
'SCTP association' instead of 'SCTP transport session', as you've  
already done in the rest of the document, except section 2.2. ("[...]  
active within a single SCTP Transport Session and [...]").

>> "Any Data Sets associated with a Template Record MUST be sent on  
>> the  same SCTP stream on which the Template Record was sent."
>> According to rfc5101, an Options Template Record is a Template  
>> Record.  Later in the same section you specify: "When the Options  
>> Template and  associated Data Records are sent in different SCTP  
>> streams, [...]".
> talk about both Options and non-Options Templates. The sentence  
> above is just about non-Options Templates.
>
> Not sure, how we can make this more comprehensible. Maybe a note in  
> the terminology section?

Yes, I agree, as you are using this terminology in the whole document.

Regards,
Tobi

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Nov 2009 11:30:50 +0900

Hi Tobias,

Thanks for your review.
>> talk about both Options and non-Options Templates. The sentence above 
>> is just about non-Options Templates.
>>
I'm not sure what is the agreement, and if we should add something in 
the terminology.
If yes, what do you suggest?

Regards, Benoit.

---

From: Tobias Limmer <[email-masked]>
Date: Thu, 12 Nov 2009 16:17:42 +0100

Hi Benoit,

On 11.11.2009, at 03:30, Benoit Claise wrote:
>>> In the text, we tried to consistently use "(Options) Template" if  
>>> we talk about both Options and non-Options Templates. The sentence  
>>> Not sure, how we can make this more comprehensible. Maybe a note  
>>> in the terminology section?
>>
> I'm not sure what is the agreement, and if we should add something  
> in the terminology.

Maybe something like:

Term Template has been ambiguously defined in [RFC5101]. In this  
document, Template and Options Template describe disjoint sets, and  
Template is not used as generic term for Options Template.

Bye,
Tobi

---

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Nov 2009 16:25:12 +0100

greetings Tobi, Benoit, all,

Template and Options Template aren't disjoint sets, and are not  
defined ambiguously. An Options Template is essentially a subclass of  
Template. There's simply no abstract superclass by which we can refer  
to "Template but not Options Template" as separate from "Template  
including Options Template". So introducing this language here risks  
confusing the point more, I think.

Suggest instead "Note that in this document, "'(Options) Template' is  
used in this document to refer to Templates and Options Templates."

Regards,

Brian

On Nov 12, 2009, at 4:17 PM, Tobias Limmer wrote:

>>>> we talk about both Options and non-Options Templates. The  
>>>> sentence above is just about non-Options Templates.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Nov 2009 00:33:00 +0900

Tobias, Brian,
> used in this document to refer to Templates and Options Templates."
I like what Brian proposal because, when I read "In this document, 
Template and Options Template describe disjoint sets, and Template is 
not used as generic term for Options Template.", it seems that there is 
something wrong with the terminology... and this is not the case.
Brian's proposal is actually a clarification, which is always good!

Regards, Benoit.

---

From: Tobias Limmer <[email-masked]>
Date: Thu, 12 Nov 2009 17:40:03 +0100

Benoit, Brian,

On 12.11.2009, at 16:33, Benoit Claise wrote:
>> defined ambiguously. An Options Template is essentially a subclass  
>> of Template. There's simply no abstract superclass by which we can  
>> refer to "Template but not Options Template" as separate from  
>> "Template including Options Template". So introducing this language  
>> here risks confusing the point more, I think.
>>
>> Suggest instead "Note that in this document, "'(Options) Template'  
>> is used in this document to refer to Templates and Options  
>> Templates."
> Template and Options Template describe disjoint sets, and Template  
> is not used as generic term for Options Template.", it seems that  
> there is something wrong with the terminology... and this is not the  
> case.

Hm. Brian's proposal is very vague about my main issue, that Options  
Template is not a subclass of Template. In my opinion, this is a small  
ambiguity in in the terminology of rfc5101, and I wanted to explicitly  
clarify this problem.

But maybe it's just my way of thinking that's getting in the way here?

Bye,
Tobi

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 12 Nov 2009 17:48:38 +0100

Hi all,

 >>> Isn't this a contradiction, or am I missing something here?

Even if we can add Brian's sentence to the terminology section, this 
does not help here.

So, in addition to Brian's proposal, we could replace "Template Record" 
by "non-Option Template Record" in the first sentence. Of course, the 
sentence becomes messy :(

Regards,
Gerhard

---

From: Brian Trammell <[email-masked]>
Date: Fri, 13 Nov 2009 15:10:40 +0100

How about, to maximize clarity:

Terminology:

Note that in this document, '(Options) Template'  is used in this  
document to refer to Templates and Options Templates. Unless otherwise  
specified, 'Template' alone refers to Templates exclusive of Options  
Templates.

4.2 paragraph 3:

OLD:

Any Data Sets associated with a Template Record MUST be sent on the  
same SCTP stream on which the Template Record was sent.

NEW:

Data Sets associated with a Template Record MUST be sent on the same  
SCTP stream on which the Template Record was sent. Options MAY be sent  
on SCTP streams other than that on which the Options Template Record  
associated with them was sent.

Regards,

Brian

On Nov 12, 2009, at 5:48 PM, Gerhard Muenz wrote:

> So, in addition to Brian's proposal, we could replace "Template  
> Record" by "non-Option Template Record" in the first sentence. Of  
> course, the sentence becomes messy :(
>
> Regards,
> Gerhard
>
>
>
> Tobias Limmer wrote:
>> Benoit, Brian,
>>>> defined ambiguously. An Options Template is essentially a  
>>>> subclass  of Template. There's simply no abstract superclass by  
>>>> which we can  refer to "Template but not Options Template" as  
>>>> separate from  "Template including Options Template". So  
>>>> introducing this language  here risks confusing the point more, I  
>>>> think.
>>>>
>>>> Suggest instead "Note that in this document, "'(Options)  
>>>> Template'  is used in this document to refer to Templates and  
>>>> Options  Templates."
>>> I like what Brian proposal because, when I read "In this  
>>> document,  Template and Options Template describe disjoint sets,  
>>> and Template  is not used as generic term for Options Template.",  
>>> it seems that  there is something wrong with the terminology...  
>>> and this is not the  case.
>> Hm. Brian's proposal is very vague about my main issue, that  
>> Options  Template is not a subclass of Template. In my opinion,  
>> this is a small  ambiguity in in the terminology of rfc5101, and I  
>> wanted to explicitly  clarify this problem.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Nov 2009 19:39:18 +0900

Randy, Michael,

As SCTP experts, are you able to help on this one below.

Thanks and regards, Benoit.
>> "3. A Data Record is received unreliably although it is expected to 
>> be  sent reliably (due to a previously received Data Record 
>> associated  with the Data Record Reliability Options Template)."
>>
>> determine which SCTP messages were sent unreliably? I did not find 
>> any  indication of that in rfc3758. The receiving side only knows 
>> if  complete messages or fragments are skipped.
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Nov 2009 19:15:59 +0900

Brian,
>>
>>
>> A suggestion not strictly limited to applicability:
>>
>>
>> 4.1 dataRecordsReliability Information Element
>>
>> [This information element is specified to only apply to Template ID 
>> scopes. Could it not also be scoped to other things (SCTP Stream ID, 
>> for instance) for a generalization of the approach? suggest the 
>> following:]
>>
>> OLD:
>>    dataRecordsReliability
>>
>>          Description:
>>               The Data Records reliability associated with this
>>               Template ID.  The true value means that the Data Records
>>               are sent reliably, while the false value means that the
>>               Data Records are not sent reliably.
>>
>> NEW:
>>   dataRecordsReliability
>>
>>     Description:
>>
>>       The Data Records reliability associated with the elements in
>>        the Options Template scope, usually a templateID. A true value
>>        means that the Data Records are sent reliably, while a false 
>> value
>>        means that the Data Records are not sent reliably.
> Great suggestion.
Actually, you took the dataRecordsReliability definition from 
draft-ietf-ipfix-export-per-sctp-stream-03
 and not from draft-ietf-ipfix-export-per-sctp-stream-04.
This is the change I applied.

OLD:
     4.1. New Information Element

        dataRecordsReliability
        
           Description:
                The reliability of the export of Data Records, within
                this SCTP stream, for all Data Records associated with a
                given Template ID.  A value of 'true' means that the
                Exporting Process MUST send any Data Records associated
                with the Template ID reliably within this SCTP stream. 
                A value of 'false' means that the Exporting Process MAY
                send any Data Records associated with the Template ID
                unreliably within this SCTP stream.

NEW:
     4.1. New Information Element

        dataRecordsReliability
        
           Description:
                The reliability of the export of Data Records, within
                this SCTP stream, for the element(s) in the Options 
Template
                scope, usually a templateID.  A value of 'true' means 
that the
                Exporting Process MUST send any Data Records associated
                with the Template ID reliably within this SCTP stream. 
                A value of 'false' means that the Exporting Process MAY
                send any Data Records associated with the Template ID
                unreliably within this SCTP stream.
                
Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 13 Nov 2009 15:29:18 +0100

hi Benoit,

This change looks good.

Best regards,

Brian

On Nov 13, 2009, at 11:15 AM, Benoit Claise wrote:

>>> [This information element is specified to only apply to Template  
>>> ID scopes. Could it not also be scoped to other things (SCTP  
>>> Stream ID, for instance) for a generalization of the approach?  
>>> suggest the following:]
>>>
>>> OLD:
>>>   dataRecordsReliability
>>>
>>>         Description:
> Actually, you took the dataRecordsReliability definition from draft- 
> ietf-ipfix-export-per-sctp-stream-03
>               with the Template ID reliably within this SCTP  
> stream.                A value of 'false' means that the Exporting  
> Process MAY
>               with the Template ID reliably within this SCTP  
> stream.                A value of 'false' means that the Exporting  
> Process MAY

---

From: Benoit Claise <[email-masked]>
Date: Sun, 15 Nov 2009 10:19:12 +0100

Gerhard,
> Even if we can add Brian's sentence to the terminology section, this 
You're right. I should have paid more attention to Tobi's problem 
description.

Regards, Benoit.
>>>> "Template including Options Template". So introducing this 
>>>> language  here risks confusing the point more, I think.
>>>>
>>> there is something wrong with the terminology... and this is not 
>>> the  case.
>> Template is not a subclass of Template. In my opinion, this is a 
>> small  ambiguity in in the terminology of rfc5101, and I wanted to 
>> explicitly  clarify this problem.
>>

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Nov 2009 16:27:30 +0100

Hi Benoit,

if a message is received, the receiver has no indication whether it was sent
reliably or not.

Best regards
Michael
On Nov 13, 2009, at 11:39 AM, Benoit Claise wrote:

>>> "3. A Data Record is received unreliably although it is expected to be  sent reliably (due to a previously received Data Record associated  with the Data Record Reliability Options Template)."
>>> 
>>> Is it possible for the receiving side of a SCTP connection to  determine which SCTP messages were sent unreliably? I did not find any  indication of that in rfc3758. The receiving side only knows if  complete messages or fragments are skipped.
>>