Subject: RE: [ipfix-eval] On template negotiation "complexity" in CRANE

From: "Carter Bullard" <[email-masked]>
Date: Thu, 31 Oct 2002 14:58:04 -0500

Hey Peter,
There is one combination that is missing that I think
is important.

  Exporter says: "I am outputting fields a,b,c,d,e,."
  Collector says: [no response]
  Exporter sends data.

While it may seem counter-intuitive to support this option,
it is the current state of the industry.  Can Crane handle
this type of negotiation?

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]] On
Behalf Of Peter Ludemann
Sent: Thursday, October 31, 2002 2:25 PM
To: [email-masked]
Subject: [ipfix-eval] On template negotiation "complexity" in CRANE

From some of the emails in the IPFIX group, there seems to be a worry
that the CRANE protocol's template negotiation is a complicated thing.
This note will explain how a minimal conforming implementation does not
need to be complex. I hope that the advantages of template negotiation
are obvious: if not, I'll write a separate note on that.

I'll present template negotiation in a series of more complex scenarios.
Each one of these scenarios is a conforming implementation of the CRANE
protocol. For simplicity, the details of the CRANE messages have been
left out; if anybody wants them, I can send a separate note. No
negotiation by collector: 
Exporter says: "I am outputting fields a,b,c,d,e." 
Collector says: "I agree; please send everything."
No negotiation by exporter: 
Exporter says: "I am outputting fields a,b,c,d,e." 
Collector says: "I only want fields a,c,e." 
Exporter says: "Too bad, I'm sending all fields anyway." 
Collector  replies "OK" and says to itself: "Oh well, I can just throw
away what I don't need". Negotiation by collector and exporter: 
Exporter says: "I am outputting fields a,b,c,d,e." 
Collector says: "I only want fields a,c,e." 
Exporter says: "Fine, I am outputting fields a,c,e." To itself, it says:
"And I can save some processing time by not computing the data for
fields b,d." Reconnecting (negotiation has been done sometime in the
past and we want to get data transferring started as soon as possible): 
Collector says to Exporter: "Tell me briefly what you're exporting" 
Exporter says: "I have fields a,b,c,d,e available but am only sending
"a,c,e", as was previously agreed. 
Collector says to Exporter: "Fine, send data please." Negotiation by
multiple collectors and an exporter (reliability mode with fail-over): 
Exporter says to Collector 1: "I am outputting fields a,b,c,d,e." 
Collector 1 says: "I only want fields a,c,e."   
Exporter says to Collector 2: "I am outputting only fields a,c,e from
the possible list of a,b,c,d,e". 
Collector 2 says: But I want fields a,b,c,e." 
Exporter says to Collector 1: "I am outputting fields a,b,c,e." 
Collector 1 says: " I only want fields a,c,e." 
Exporter says to Collector 1: "Too bad, I'm sending fields a,b,c,e
anyway." 
Exporter says to Collector 2: "I'm sending fields a,b,c,e."  
Collectors 1 and 2 respond with "OK".
The last scenario is a bit extreme because all the collectors should be
configured to want the same fields. But it is a possibility, if the
collectors or exporters are being upgraded in a "non-stop" environment
and the configuration is being changed on the fly (e.g., a new exporter
has additional fields; or there is a change in the amount of detail
being collected).

With multiple collectors, the exporter controls the negotiation
conversation. There is no assumption that the collectors can communicate
with each other. The exporter can decide at any point to stop the
discussion and dictate what fields will be transmitted, thus ensuring
that the conversation terminates.

As you can see, the simplest scenario (#1) requires almost no work to
implement. The exporter denies all negotiation request and always sends
everything.

- peter

--
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: "Carter Bullard" <[email-masked]>
Date: Thu, 31 Oct 2002 14:58:08 -0500

Hey Peter,

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

-----Original Message-----

- peter

---

From: "Peter Ludemann" <[email-masked]>
Date: Thu, 31 Oct 2002 12:16:40 -0800

Carter Bullard [mailto:[email-masked]] wrote Thursday, October 31, 2002

> this type of negotiation?

Yes, but not with [no response].  [no response] is not allowed by the CRANE
protocol.  Instead, use a "I agree" response. The exporter makes the final
decision as to what is exported, so there is no problem with a single
collector just accepting whatever it is told.

Our general philosophy is to require some kind of an acknowledgment to all
messages. (Data messages are acknowledged in groups; all others are
acknowledged individually.) For some messages, acknowledgment can be
"asynchronous" (e.g., a request is sent with a request ID, which is used to
identify the response).

We think that it is a Bad Thing to allow silence to be equivalent to an
acknowledgment. This is particularly the case for a compact binary protocol:
if there is a mismatch between what the exporter is sending and what the
collector is expecting, the only indication of a problem might be when
somebody notices strange values showing up in the data.

- peter