Subject: Re: [ANCP] Bulk Transaction Message

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 6 May 2008 18:42:25 +0200

Hi Folks,
 
given that no discernable use of Bulk messaging has been identified, nor
there being a good reason for it given the fact that ANCP is bound to
the TCP transport (or equivalent), I would like to propose to remove all
of the text relating to this capability and associated message from the
protocol spec draft.
 
Regards,
Woj.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
	Sent: 20 April 2008 15:18
	To: Peter Arberg; [email-masked]
	Subject: Re: [ANCP] Bulk Transaction Message

	Should also have added: Given that currently the bulk message
does not appear to have had any practical adoption, having the DTeam
adopt it/modify it, or possibly have it removed from the spec all
together are all valid options.
	 
	-Woj.

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
		Sent: 20 April 2008 14:39
		To: Peter Arberg; [email-masked]
		Subject: Re: [ANCP] Bulk Transaction Message

		It's all simple:
		- the Design Team is looking at the possibility of using
this message
		- the message in its current form does not appear to be
terribly useful, and could be removed from the spec.
		 
		-Woj.

________________________________

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Arberg
			Sent: 19 April 2008 03:07
			To: Wojciech Dec (wdec); [email-masked]
			Subject: Re: [ANCP] Bulk Transaction Message

			Hi Woj,
			 
			can you give a little background to why you are
looking for vendor
			implementation support for this specific
capability & message ?
			 
			thanks,
			Peter

________________________________

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
				Sent: 18. april 2008 08:04
				To: [email-masked]
				Subject: [ANCP] Bulk Transaction Message

				Hi Folks, 

				Could you please let me/us know if you
currently have an implementation of ANCP that supports the Bulk
Transaction Capability and Message?

				Thanks, 
				Woj. 

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 6 May 2008 13:08:15 -0400

Woj
  It is a bad idea to remove bulk-transaction capability from the draft.
On one hand you are trying to add "marginally useful" extensions (with
TLVs), and on the other hand you are arguing for removing useful
abstractions which can help with scaling. If bulk-transaction capability
needs to be augmented or modified, then we should consider augmenting
it, rather than removing it from the draft.
 
Cheers
-Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Wojciech Dec (wdec)
Sent: Tuesday, May 06, 2008 12:42 PM
To: Peter Arberg; [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

Hi Folks,

Regards,
Woj.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: 20 April 2008 15:18
To: Peter Arberg; [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

Should also have added: Given that currently the bulk message does not
appear to have had any practical adoption, having the DTeam adopt
it/modify it, or possibly have it removed from the spec all together are
all valid options.
 
-Woj.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: 20 April 2008 14:39
To: Peter Arberg; [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

It's all simple:
- the Design Team is looking at the possibility of using this message
- the message in its current form does not appear to be terribly useful,
and could be removed from the spec.
 
-Woj.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Arberg
Sent: 19 April 2008 03:07
To: Wojciech Dec (wdec); [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

Hi Woj,
 
can you give a little background to why you are looking for vendor
implementation support for this specific capability & message ?
 
thanks,
Peter

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: 18. april 2008 08:04
To: [email-masked]
Subject: [ANCP] Bulk Transaction Message

Hi Folks, 

Could you please let me/us know if you currently have an implementation
of ANCP that supports the Bulk Transaction Capability and Message?

Thanks, 
Woj.

---

From: Peter Arberg <[email-masked]>
Date: Tue, 6 May 2008 10:23:38 -0700

Hi,

I agree with this proposal.

cheers,
Peter

________________________________
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: 6. maj 2008 09:42
To: Peter Arberg; [email-masked]
Subject: RE: [ANCP] Bulk Transaction Message

Hi Folks,

given that no discernable use of Bulk messaging has been identified, nor there being a good reason for it given the fact that ANCP is bound to the TCP transport (or equivalent), I would like to propose to remove all of the text relating to this capability and associated message from the protocol spec draft.

Regards,
Woj.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)

Should also have added: Given that currently the bulk message does not appear to have had any practical adoption, having the DTeam adopt it/modify it, or possibly have it removed from the spec all together are all valid options.

-Woj.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)

It's all simple:
- the Design Team is looking at the possibility of using this message
- the message in its current form does not appear to be terribly useful, and could be removed from the spec.

-Woj.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Arberg

Hi Woj,

thanks,
Peter

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: 18. april 2008 08:04
To: [email-masked]
Subject: [ANCP] Bulk Transaction Message

Hi Folks,

Could you please let me/us know if you currently have an implementation of ANCP that supports the Bulk Transaction Capability and Message?

Thanks,
Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 6 May 2008 19:24:18 +0200

Sanjay,
 
can you please present to the WG and myself how bulk transaction
capability is useful in any way in terms of scaling for example? And by
the way, please treat this discussion is orthogonal to any other.
 
Cheers,
Woj.

	From: Sanjay Wadhwa [mailto:[email-masked]] 
	Sent: 06 May 2008 19:08
	To: Wojciech Dec (wdec); Peter Arberg; [email-masked]
	Subject: RE: [ANCP] Bulk Transaction Message

	Woj
	  It is a bad idea to remove bulk-transaction capability from
the draft. On one hand you are trying to add "marginally useful"
extensions (with TLVs), and on the other hand you are arguing for
removing useful abstractions which can help with scaling. If
bulk-transaction capability needs to be augmented or modified, then we
should consider augmenting it, rather than removing it from the draft.
	 
	Cheers
	-Sanjay

		-----Original Message-----
[mailto:[email-masked]]On Behalf Of Wojciech Dec (wdec)

		Hi Folks,
		 
		given that no discernable use of Bulk messaging has been
identified, nor there being a good reason for it given the fact that
ANCP is bound to the TCP transport (or equivalent), I would like to
propose to remove all of the text relating to this capability and
associated message from the protocol spec draft.
		 
		Regards,
		Woj.

			Should also have added: Given that currently the
bulk message does not appear to have had any practical adoption, having
the DTeam adopt it/modify it, or possibly have it removed from the spec
all together are all valid options.
			 
			-Woj.

				Subject: Re: [ANCP] Bulk Transaction
Message

				It's all simple:
				- the Design Team is looking at the
possibility of using this message
				- the message in its current form does
not appear to be terribly useful, and could be removed from the spec.
				 
				-Woj.

				Subject: Re: [ANCP] Bulk Transaction
Message

				Hi Woj,
				 
				can you give a little background to why
you are looking for vendor
				implementation support for this specific
capability & message ?
				 
				thanks,
				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Tue, 6 May 2008 19:32:44 +0200

I agree with Woj's proposal under 1 condition: if bulk messages are
removed, it does not mean that other optimization methods are now Ok
which were previously not Ok because there was already bulk messages.
If someone in the future proposes to optimize ANCP in some way (e.g., by
defining new TLVs) then at that time bulk messaging should be considered
again as possible candidate for optimization the protocol.  I like bulk
messages but I can understand that at this stage, no optimizations are
needed and that making the protocol more scalable is a topic for the
future.
 
regards,
Stefaan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: dinsdag 6 mei 2008 18:42
To: Peter Arberg; [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

Hi Folks,

Regards,
Woj.

	 
	-Woj.

		It's all simple:
		 
		-Woj.

			Hi Woj,

			thanks,
			Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 6 May 2008 20:03:10 -0400

Even with transport being TCP, I see atleast a couple of benefits:
 
1. If a sender knows it has a bunch of messages to send (e.g. ANCP
adjacency flaps, and all the port-up messages need to re-played), then
bulking by definition allows the application to invoke TCP fewer times
to transmit everything that it needs to transmit, which in a lot of
systems can translate to significant compute and memory efficiency
(specially, if we are considering a large amount of state). This is not
to say one can't realize this in an implementation specific way. 
However, if neeeded, bulking also has the benefit of affording optimized
acking (e.g. if no error is encountered in proccessing all the
sub-messages in the bundled message, it is possible for the receiver to
send a cummulative ack to the sender rather than individual acks).
 
2. Bulking also provides a nice solution if one ever needed to
atomically receive and process *distinct* ANCP message types. 
 
What is the downside of having it? It is negotiable as an optional
capability.
 
Cheers
-Sanjay

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: Tuesday, May 06, 2008 1:24 PM
To: Sanjay Wadhwa; Peter Arberg; [email-masked]
Subject: RE: [ANCP] Bulk Transaction Message

Sanjay,

Cheers,
Woj.

  _____  

Woj
 
Cheers
-Sanjay

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

Hi Folks,

Regards,
Woj.

  _____  

 
-Woj.

  _____  

It's all simple:
 
-Woj.

  _____  

Hi Woj,

thanks,
Peter

  _____  

Hi Folks, 

Thanks, 
Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 May 2008 09:31:56 +0200

Sanjay,
 
inline

	Sent: 07 May 2008 02:03

	Even with transport being TCP, I see atleast a couple of
benefits:
	 
	1. If a sender knows it has a bunch of messages to send (e.g.
ANCP adjacency flaps, and all the port-up messages need to re-played),
then bulking by definition allows the application to invoke TCP fewer
times to transmit everything that it needs to transmit, which in a lot
of systems can translate to significant compute and memory efficiency
(specially, if we are considering a large amount of state). This is not
to say one can't realize this in an implementation specific way.  
	 
	Woj> Even with bulking one needs to realize the TCP interaction
with some thought. Perhaps bulking indeed offers the opportunity for a
delveloper to think about that, but I seriously doubt that anyone
familar with TCP app development would overlook this aspect in the first
place.
	 
	However, if neeeded, bulking also has the benefit of affording
optimized acking (e.g. if no error is encountered in proccessing all the
sub-messages in the bundled message, it is possible for the receiver to
send a cummulative ack to the sender rather than individual acks). 
	 
	Woj> A cumulatitive ack would appear to be desirable in some
cases, but I see this as very different to the bulk ack currently
described which essenatially carries in bulk all of the individal acks.
The bulking mechanism is quite clear in saying that each ANCP message is
bundled header and all, and acted upon individually by the recipient,
and whether it's a request or an ack is secondary. I'm sure you'll agree
that this is undesirable overhead and complexity for what it's worth,
also in view of the fact that "something" on the recipient side would
need to decide what ack/nack goes into a bulk response and what doesn't.

	Having a cumulatitive ack is an all thogether different thing,
which I would support, and it should not involve the "bulking" of each
indivdual ack, and is an item that for which proposals are welcome.

	Woj> There appears to be no such thing; in bulking, presumably
the reciever would have to buffer all the way until the end of the bulk
message, and then process each message individually. This seems rather
overweight when compared to simply sending each message again.
	 
	What is the downside of having it? It is negotiable as an
optional capability. 
	 
	Woj> A couple of reasons come to the fore; i) no body saw a good
reason so far to implement it/use it ii) it's added protocol "stuff"
that has no clear benefit, does not realize any new use-case, does not
optimize much, and in fact as mentioned above it appears to rather have
some downsides such as extra overhead, buffering and delay. Let's now
have the axe fall...
	 
	Cheers,
	Woj.
	 
	Cheers
	-Sanjay

		-----Original Message-----
		From: Wojciech Dec (wdec) [mailto:[email-masked]]
		Sent: Tuesday, May 06, 2008 1:24 PM
		To: Sanjay Wadhwa; Peter Arberg; [email-masked]
		Subject: RE: [ANCP] Bulk Transaction Message

		Sanjay,
		 
		can you please present to the WG and myself how bulk
transaction capability is useful in any way in terms of scaling for
example? And by the way, please treat this discussion is orthogonal to
any other.
		 
		Cheers,
		Woj.

			Sent: 06 May 2008 19:08
			To: Wojciech Dec (wdec); Peter Arberg;
[email-masked]
			Subject: RE: [ANCP] Bulk Transaction Message

			Woj
			  It is a bad idea to remove bulk-transaction
capability from the draft. On one hand you are trying to add "marginally
useful" extensions (with TLVs), and on the other hand you are arguing
for removing useful abstractions which can help with scaling. If
bulk-transaction capability needs to be augmented or modified, then we
should consider augmenting it, rather than removing it from the draft.
			 
			Cheers
			-Sanjay

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

				Hi Folks,
				 
				given that no discernable use of Bulk
messaging has been identified, nor there being a good reason for it
given the fact that ANCP is bound to the TCP transport (or equivalent),
I would like to propose to remove all of the text relating to this
capability and associated message from the protocol spec draft.
				 
				Regards,
				Woj.

				Should also have added: Given that
currently the bulk message does not appear to have had any practical
adoption, having the DTeam adopt it/modify it, or possibly have it
removed from the spec all together are all valid options.
				 
				-Woj.

				It's all simple:
				 
				-Woj.

				Hi Woj,

				thanks,
				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Wed, 7 May 2008 10:02:26 -0400

Woj

  Inline [SW].

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Wednesday, May 07, 2008 3:32 AM
To: Sanjay Wadhwa; Peter Arberg; [email-masked]
Subject: RE: [ANCP] Bulk Transaction Message

Sanjay,

inline

	[[SW]] I would like to believe it. History doesn't bear this
though.

	[[SW]] Sorry, I should have been clearer. Bulking adds an
overall header for the individual messages being bulked. If all the
messages succeed, we can define the behavior to send a single ACK (NOT a
bulk ACK composed of individual sub-messages carrying ACK) with the
transaction-ID of the main header reflected back in the ACK.  This
provides an elegant way to address cumulative ACK. This is not defined
in the draft today (see "if needed" above), but is easily provided by
bulking, and can be added if we agree.

	Far as request message is concerned, having individual messages
(with their own header) in the request reduces complexity, provides a
way to bulk messages of different types if needed. It allows each
sub-message to be individually NACK'd where required. Bulking in such a
way allows the flexibility of treating individual sub-messages as
completely independent or related.

	Woj> There appears to be no such thing; 

	[[SW]] Today, but as you mentioned in another thread, we need to
design the protocol to be generic in anticipation of such requirements.

	in bulking, presumably the reciever would have to buffer all the
way until the end of the bulk message, and then process each message
individually. This seems rather overweight when compared to simply
sending each message again.

	[[SW]] Draft doesn't impose on how much you bulk. If atomicity
in handling of bulked messages is warranted by a use-case, then yes you
want to get the entire message. If not, you could presumably process as
you receive each complete sub-message within the bundle.

some downsides such as extra overhead, buffering and delay.

	Let's now have the axe fall...

	[[SW]] Let us please not be dismissive towards something that
has benefits (as outlined above).

	Cheers

	-Sanjay

		-----Original Message-----
		From: Wojciech Dec (wdec) [mailto:[email-masked]]
		Sent: Tuesday, May 06, 2008 1:24 PM
		To: Sanjay Wadhwa; Peter Arberg; [email-masked]
		Subject: RE: [ANCP] Bulk Transaction Message

		Sanjay,

		Cheers,

		Woj.

			Sent: 06 May 2008 19:08

			Woj

			Cheers

			-Sanjay

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

				Hi Folks,

				Regards,

				Woj.

				-Woj.

				It's all simple:

				-Woj.

				Hi Woj,

				thanks,

				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 May 2008 16:26:44 +0200

Sanjay,
 
inline woj#2>

	Sent: 07 May 2008 16:02

	Woj

	  Inline [SW].

	Sanjay,

	inline

		1. If a sender knows it has a bunch of messages to send
(e.g. ANCP adjacency flaps, and all the port-up messages need to
re-played), then bulking by definition allows the application to invoke
TCP fewer times to transmit everything that it needs to transmit, which
in a lot of systems can translate to significant compute and memory
efficiency (specially, if we are considering a large amount of state).
This is not to say one can't realize this in an implementation specific
way.  

		Woj> Even with bulking one needs to realize the TCP
interaction with some thought. Perhaps bulking indeed offers the
opportunity for a delveloper to think about that, but I seriously doubt
that anyone familar with TCP app development would overlook this aspect
in the first place.

		[[SW]] I would like to believe it. History doesn't bear
this though. 

		Woj#2> Unless the spec forces Bulking to be used for
every single multi-message exchange, the bunching effect will not
appear, nor will any optimization.

		However, if neeeded, bulking also has the benefit of
affording optimized acking (e.g. if no error is encountered in
proccessing all the sub-messages in the bundled message, it is possible
for the receiver to send a cummulative ack to the sender rather than
individual acks). 

		Woj> A cumulatitive ack would appear to be desirable in
some cases, but I see this as very different to the bulk ack currently
described which essenatially carries in bulk all of the individal acks.
The bulking mechanism is quite clear in saying that each ANCP message is
bundled header and all, and acted upon individually by the recipient,
and whether it's a request or an ack is secondary. I'm sure you'll agree
that this is undesirable overhead and complexity for what it's worth,
also in view of the fact that "something" on the recipient side would
need to decide what ack/nack goes into a bulk response and what doesn't.

		Having a cumulatitive ack is an all thogether different
thing, which I would support, and it should not involve the "bulking" of
each indivdual ack, and is an item that for which proposals are welcome.

		[[SW]] Sorry, I should have been clearer. Bulking adds
an overall header for the individual messages being bulked. If all the
messages succeed, we can define the behavior to send a single ACK (NOT a
bulk ACK composed of individual sub-messages carrying ACK) with the
transaction-ID of the main header reflected back in the ACK.  This
provides an elegant way to address cumulative ACK. This is not defined
in the draft today (see "if needed" above), but is easily provided by
bulking, and can be added if we agree.

		Far as request message is concerned, having individual
messages (with their own header) in the request reduces complexity,
provides a way to bulk messages of different types if needed. It allows
each sub-message to be individually NACK'd where required. Bulking in
such a way allows the flexibility of treating individual sub-messages as
completely independent or related. 

		Woj#2> The above, in principle is fine, BUT it is far
removed from the current bulking mechanism. The order would be to have a
proposal regarding this on its own right. 

		2. Bulking also provides a nice solution if one ever
needed to atomically receive and process *distinct* ANCP message types.

		[[SW]] Today, but as you mentioned in another thread, we
need to design the protocol to be generic in anticipation of such
requirements. 

		Woj#2> What tentative requirements are you referring to,
a relay? If so, bulking doesn't help there. This is also much different
from a discussion about a generic TLV format that is to be used by the
protocol.

		in bulking, presumably the reciever would have to buffer
all the way until the end of the bulk message, and then process each
message individually. This seems rather overweight when compared to
simply sending each message again.

		[[SW]] Draft doesn't impose on how much you bulk. If
atomicity in handling of bulked messages is warranted by a use-case,
then yes you want to get the entire message. If not, you could
presumably process as you receive each complete sub-message within the
bundle. 

		Woj#2> Adding a single bulk envelope and sending inside
it 100 messages vs 2 bulk envelopes with 50 messages is also pretty
pointless, and an exercise in optimizing something that isn't needed in
the first place: In each case you're still sending 100 messages! The
downside is that in either of the bulked messages case you generally
will have to wait till the full message is received. There are betterTCP
access 

		What is the downside of having it? It is negotiable as
an optional capability. 

		Woj> A couple of reasons come to the fore; i) no body
saw a good reason so far to implement it/use it ii) it's added protocol
"stuff" that has no clear benefit, does not realize any new use-case,
does not optimize much, and in fact as mentioned above it appears to
rather have some downsides such as extra overhead, buffering and delay.

		[[SW]] Let us please not be dismissive towards something
that has benefits (as outlined above). 

		Wo#2j>  With the exception of cumulative ack, which does
deserve a standalone proposal to be put forward, neither me nor other
members of the WG do appear to share the views regarding the purported
benefits on bulking, nor a desire to retain it in the spec. Sorry, it
just needs to go.

		Cheers,

		Woj.

		Cheers

		-Sanjay

			-----Original Message-----
			From: Wojciech Dec (wdec)
[mailto:[email-masked]]
			Sent: Tuesday, May 06, 2008 1:24 PM
			To: Sanjay Wadhwa; Peter Arberg; [email-masked]
			Subject: RE: [ANCP] Bulk Transaction Message

			Sanjay,

			can you please present to the WG and myself how
bulk transaction capability is useful in any way in terms of scaling for
example? And by the way, please treat this discussion is orthogonal to
any other.

			Cheers,

			Woj.

				From: Sanjay Wadhwa
[mailto:[email-masked]] 
				Sent: 06 May 2008 19:08
				To: Wojciech Dec (wdec); Peter Arberg;
[email-masked]
				Subject: RE: [ANCP] Bulk Transaction
Message

				Woj

				  It is a bad idea to remove
bulk-transaction capability from the draft. On one hand you are trying
to add "marginally useful" extensions (with TLVs), and on the other hand
you are arguing for removing useful abstractions which can help with
scaling. If bulk-transaction capability needs to be augmented or
modified, then we should consider augmenting it, rather than removing it
from the draft.

				Cheers

				-Sanjay

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

				Hi Folks,

				Regards,

				Woj.

				-Woj.

				It's all simple:

				-Woj.

				Hi Woj,

				thanks,

				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 7 May 2008 16:46:49 +0200

Should have added: Please feel free to put forward a bulk ack proposal
to the WG. Just axe the existing bulking text before someone goes starts
thinking of actually adopting it.
 
-Woj.

	Sent: 07 May 2008 16:27

	Sanjay,
	 
	inline woj#2>

		Woj

		  Inline [SW].

		Sanjay,

		inline

			Sent: 07 May 2008 02:03

			Even with transport being TCP, I see atleast a
couple of benefits:

			1. If a sender knows it has a bunch of messages
to send (e.g. ANCP adjacency flaps, and all the port-up messages need to
re-played), then bulking by definition allows the application to invoke
TCP fewer times to transmit everything that it needs to transmit, which
in a lot of systems can translate to significant compute and memory
efficiency (specially, if we are considering a large amount of state).
This is not to say one can't realize this in an implementation specific
way.  

			Woj> Even with bulking one needs to realize the
TCP interaction with some thought. Perhaps bulking indeed offers the
opportunity for a delveloper to think about that, but I seriously doubt
that anyone familar with TCP app development would overlook this aspect
in the first place.

			[[SW]] I would like to believe it. History
doesn't bear this though. 

			Woj#2> Unless the spec forces Bulking to be used
for every single multi-message exchange, the bunching effect will not
appear, nor will any optimization.

			However, if neeeded, bulking also has the
benefit of affording optimized acking (e.g. if no error is encountered
in proccessing all the sub-messages in the bundled message, it is
possible for the receiver to send a cummulative ack to the sender rather
than individual acks). 

			Woj> A cumulatitive ack would appear to be
desirable in some cases, but I see this as very different to the bulk
ack currently described which essenatially carries in bulk all of the
individal acks. The bulking mechanism is quite clear in saying that each
ANCP message is bundled header and all, and acted upon individually by
the recipient, and whether it's a request or an ack is secondary. I'm
sure you'll agree that this is undesirable overhead and complexity for
what it's worth, also in view of the fact that "something" on the
recipient side would need to decide what ack/nack goes into a bulk
response and what doesn't. 

			Having a cumulatitive ack is an all thogether
different thing, which I would support, and it should not involve the
"bulking" of each indivdual ack, and is an item that for which proposals
are welcome.

			[[SW]] Sorry, I should have been clearer.
Bulking adds an overall header for the individual messages being bulked.
If all the messages succeed, we can define the behavior to send a single
ACK (NOT a bulk ACK composed of individual sub-messages carrying ACK)
with the transaction-ID of the main header reflected back in the ACK.
This provides an elegant way to address cumulative ACK. This is not
defined in the draft today (see "if needed" above), but is easily
provided by bulking, and can be added if we agree.

			Far as request message is concerned, having
individual messages (with their own header) in the request reduces
complexity, provides a way to bulk messages of different types if
needed. It allows each sub-message to be individually NACK'd where
required. Bulking in such a way allows the flexibility of treating
individual sub-messages as completely independent or related. 

			Woj#2> The above, in principle is fine, BUT it
is far removed from the current bulking mechanism. The order would be to
have a proposal regarding this on its own right. 

			2. Bulking also provides a nice solution if one
ever needed to atomically receive and process *distinct* ANCP message
types.  

			[[SW]] Today, but as you mentioned in another
thread, we need to design the protocol to be generic in anticipation of
such requirements. 

			Woj#2> What tentative requirements are you
referring to, a relay? If so, bulking doesn't help there. This is also
much different from a discussion about a generic TLV format that is to
be used by the protocol.

			in bulking, presumably the reciever would have
to buffer all the way until the end of the bulk message, and then
process each message individually. This seems rather overweight when
compared to simply sending each message again.

			[[SW]] Draft doesn't impose on how much you
bulk. If atomicity in handling of bulked messages is warranted by a
use-case, then yes you want to get the entire message. If not, you could
presumably process as you receive each complete sub-message within the
bundle. 

			Woj#2> Adding a single bulk envelope and sending
inside it 100 messages vs 2 bulk envelopes with 50 messages is also
pretty pointless, and an exercise in optimizing something that isn't
needed in the first place: In each case you're still sending 100
messages! The downside is that in either of the bulked messages case you
generally will have to wait till the full message is received. There are
betterTCP access 

			What is the downside of having it? It is
negotiable as an optional capability. 

			Woj> A couple of reasons come to the fore; i) no
body saw a good reason so far to implement it/use it ii) it's added
protocol "stuff" that has no clear benefit, does not realize any new
use-case, does not optimize much, and in fact as mentioned above it
appears to rather have some downsides such as extra overhead, buffering
and delay.

			[[SW]] Let us please not be dismissive towards
something that has benefits (as outlined above). 

			Wo#2j>  With the exception of cumulative ack,
which does deserve a standalone proposal to be put forward, neither me
nor other members of the WG do appear to share the views regarding the
purported benefits on bulking, nor a desire to retain it in the spec.
Sorry, it just needs to go.

			Cheers,

			Woj.

			Cheers

			-Sanjay

				-----Original Message-----
				From: Wojciech Dec (wdec)
[mailto:[email-masked]]
				Sent: Tuesday, May 06, 2008 1:24 PM
				To: Sanjay Wadhwa; Peter Arberg;
[email-masked]
				Subject: RE: [ANCP] Bulk Transaction
Message

				Sanjay,

				can you please present to the WG and
myself how bulk transaction capability is useful in any way in terms of
scaling for example? And by the way, please treat this discussion is
orthogonal to any other.

				Cheers,

				Woj.

				From: Sanjay Wadhwa

				Woj

				Cheers

				-Sanjay

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

				Hi Folks,

				Regards,

				Woj.

				-Woj.

				It's all simple:

				-Woj.

				Hi Woj,

				thanks,

				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Wed, 7 May 2008 12:07:12 -0400

Inline again [SW2]

-Sanjay

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Wednesday, May 07, 2008 10:47 AM
To: Wojciech Dec (wdec); Sanjay Wadhwa; Peter Arberg; [email-masked]
Subject: RE: [ANCP] Bulk Transaction Message

-Woj.

	Sanjay,

	inline woj#2>

		Woj

		  Inline [SW].

		Sanjay,

		inline

			Sent: 07 May 2008 02:03

			[[SW2]] It can easily be extended and doesn't
need to be done right away. Rehashing (new proposal) when you have the
basis for in the draft is not justifiable.

			 

			 [[SW2]] Sorry to repeat. If you need atomicity
for the sub-messages in the bundle, then you need to wait. If not then
you don't have to. This is providing you the flexibility, which you
don't easily have with individual messages (e.g atomic handling is hard
to realize with individual messages).

			[[SW2]] See above. This has been in the draft
for a while, and I have not seen any technical arguments from anyone
else on removing it from the draft. I have clearly outlined the benefits
above, and don't see convincing technical reasons for this to go. 

			[[SW2]] Is this with your chair hat on or as an
individual WG member? 

			Cheers,

			Woj.

			Cheers

			-Sanjay

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

				Sanjay,

				Cheers,

				Woj.

				From: Sanjay Wadhwa

				Woj

				Cheers

				-Sanjay

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

				Hi Folks,

				Regards,

				Woj.

				-Woj.

				It's all simple:

				-Woj.

				Hi Woj,

				thanks,

				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Thu, 8 May 2008 12:17:54 +0200

Hi Sanjay, Woj,
 
I see some advantages in having bulk messages to optimize ANCP.
However, bulk messages are not the only solution.  It is wrong to
discuss bulk messages without comparing it with alternatives.  It looks
like a good solution to me but maybe there are better ways in optimizing
ANCP.  So far the working group has not been working a lot on
optimizations.  According to me, keeping bulk messages in the base spec
is wrong and it should be removed.  People are invited to submit
solutions to optimize ANCP in the form of a seperate draft, and one such
draft could be bulk messages.  Then when the working group decides that
it is time to work on optimalisations, the proposed solutions can be
compared and discussed.
 
regards,
Stefaan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sanjay Wadhwa
Sent: woensdag 7 mei 2008 18:07
To: Wojciech Dec (wdec); Peter Arberg; [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

Inline again [SW2]

-Sanjay

-Woj.

	Sanjay,

	inline woj#2>

		Woj

		  Inline [SW].

		Sanjay,

		inline

			Sent: 07 May 2008 02:03

			 

			 

			Cheers,

			Woj.

			Cheers

			-Sanjay

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

				Sanjay,

				Cheers,

				Woj.

				From: Sanjay Wadhwa

				Woj

				Cheers

				-Sanjay

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

				Hi Folks,

				Regards,

				Woj.

				-Woj.

				It's all simple:

				-Woj.

				Hi Woj,

				thanks,

				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 8 May 2008 12:36:57 +0200

Sanjay,
 
(chair hat on) re-hashing arguments already made isn't going to resolve
this. In essence, there appears to be no clear and sound technical
justification/use presented for the existence of this totally *distinct*
functionality, as opposed to a by-product of an other one, whose sole
purpose is to ferry other already fully formed messages that do not
require another layer of message delineation in TCP. There also isn't
any substantial support in the WG for keeping it in the spec, but rather
the contrary (see earlier responses on the thread). Justifying its
presence as a place holder for something quite different (eg "cumulative
ACK" optimization) that is yet to come in the future is undesirable, and
equally so is keeping it on as "optional" material in the protocol that
happens to be of little practical use, if any. One possible original
justification has gone away since it became clear that the WG would not
be adopting other transports for ANCP than TCP (or equivalent) for the
time being.
As stated previously *you or anyone else* are welcome (expected?) to put
forward to the WG a detailed proposal describing "cumulative ACKs" for
acceptance in place of the Bulk Transaction. Other than this, since you
continue to believe firmly in the ANCP Bulk Transaction Mechanism as is,
then what we can offer is to welcome it back in the ANCP WG as an
individual contribution draft, and have another discussion round at
getting WG support for it. Till then, and in view of trying to get the
spec into shape for finishing it, please accept the fact that the text
is to be either removed from the WG draft-ietf-ancp-protocol spec by its
next 03 revision, or be supplanted by a WG accepted cumulative ack
proposal. 
There appears to be little reason in dragging this discussion out any
further, however if anything here still isn't clear then I do suggest a
private forum for clarifying.
 
Regards,
Woj.

	Sent: 07 May 2008 18:07

	Inline again [SW2]

	-Sanjay

	From: Wojciech Dec (wdec) [mailto:[email-masked]] 
	Sent: Wednesday, May 07, 2008 10:47 AM
	To: Wojciech Dec (wdec); Sanjay Wadhwa; Peter Arberg;
[email-masked]
	Subject: RE: [ANCP] Bulk Transaction Message

	Should have added: Please feel free to put forward a bulk ack
proposal to the WG. Just axe the existing bulking text before someone
goes starts thinking of actually adopting it.

	-Woj.

		Sanjay,

		inline woj#2>

			Sent: 07 May 2008 16:02

			Woj

			  Inline [SW].

			Sanjay,

			inline

				From: Sanjay Wadhwa

				Even with transport being TCP, I see
atleast a couple of benefits:

				1. If a sender knows it has a bunch of
messages to send (e.g. ANCP adjacency flaps, and all the port-up
messages need to re-played), then bulking by definition allows the
application to invoke TCP fewer times to transmit everything that it
needs to transmit, which in a lot of systems can translate to
significant compute and memory efficiency (specially, if we are
considering a large amount of state). This is not to say one can't
realize this in an implementation specific way.  

				Woj> Even with bulking one needs to
realize the TCP interaction with some thought. Perhaps bulking indeed
offers the opportunity for a delveloper to think about that, but I
seriously doubt that anyone familar with TCP app development would
overlook this aspect in the first place.

				[[SW]] I would like to believe it.
History doesn't bear this though. 

				Woj#2> Unless the spec forces Bulking to
be used for every single multi-message exchange, the bunching effect
will not appear, nor will any optimization.

				However, if neeeded, bulking also has
the benefit of affording optimized acking (e.g. if no error is
encountered in proccessing all the sub-messages in the bundled message,
it is possible for the receiver to send a cummulative ack to the sender
rather than individual acks). 

				Woj> A cumulatitive ack would appear to
be desirable in some cases, but I see this as very different to the bulk

				Having a cumulatitive ack is an all
thogether different thing, which I would support, and it should not
involve the "bulking" of each indivdual ack, and is an item that for
which proposals are welcome.

				[[SW]] Sorry, I should have been
clearer. Bulking adds an overall header for the individual messages
being bulked. If all the messages succeed, we can define the behavior to
send a single ACK (NOT a bulk ACK composed of individual sub-messages
carrying ACK) with the transaction-ID of the main header reflected back
in the ACK.  This provides an elegant way to address cumulative ACK.
This is not defined in the draft today (see "if needed" above), but is
easily provided by bulking, and can be added if we agree.

				Far as request message is concerned,
having individual messages (with their own header) in the request
reduces complexity, provides a way to bulk messages of different types
if needed. It allows each sub-message to be individually NACK'd where
required. Bulking in such a way allows the flexibility of treating
individual sub-messages as completely independent or related. 

				Woj#2> The above, in principle is fine,
BUT it is far removed from the current bulking mechanism. The order
would be to have a proposal regarding this on its own right. 

				[[SW2]] It can easily be extended and
doesn't need to be done right away. Rehashing (new proposal) when you
have the basis for in the draft is not justifiable.

				2. Bulking also provides a nice solution
if one ever needed to atomically receive and process *distinct* ANCP
message types.  

				[[SW]] Today, but as you mentioned in
another thread, we need to design the protocol to be generic in
anticipation of such requirements. 

				Woj#2> What tentative requirements are
you referring to, a relay? If so, bulking doesn't help there. This is
also much different from a discussion about a generic TLV format that is
to be used by the protocol.

				in bulking, presumably the reciever
would have to buffer all the way until the end of the bulk message, and
then process each message individually. This seems rather overweight
when compared to simply sending each message again.

				[[SW]] Draft doesn't impose on how much
you bulk. If atomicity in handling of bulked messages is warranted by a
use-case, then yes you want to get the entire message. If not, you could
presumably process as you receive each complete sub-message within the
bundle. 

				Woj#2> Adding a single bulk envelope and
sending inside it 100 messages vs 2 bulk envelopes with 50 messages is
also pretty pointless, and an exercise in optimizing something that
isn't needed in the first place: In each case you're still sending 100
messages! The downside is that in either of the bulked messages case you
generally will have to wait till the full message is received. There are
betterTCP access 

				 [[SW2]] Sorry to repeat. If you need
atomicity for the sub-messages in the bundle, then you need to wait. If
not then you don't have to. This is providing you the flexibility, which
you don't easily have with individual messages (e.g atomic handling is
hard to realize with individual messages).

				Woj> A couple of reasons come to the
fore; i) no body saw a good reason so far to implement it/use it ii)
it's added protocol "stuff" that has no clear benefit, does not realize
any new use-case, does not optimize much, and in fact as mentioned above
it appears to rather have some downsides such as extra overhead,
buffering and delay.

				[[SW]] Let us please not be dismissive
towards something that has benefits (as outlined above). 

				Wo#2j>  With the exception of cumulative
ack, which does deserve a standalone proposal to be put forward, neither
me nor other members of the WG do appear to share the views regarding
the purported benefits on bulking, nor a desire to retain it in the
spec. 

				[[SW2]] See above. This has been in the
draft for a while, and I have not seen any technical arguments from
anyone else on removing it from the draft. I have clearly outlined the
benefits above, and don't see convincing technical reasons for this to
go. 

				[[SW2]] Is this with your chair hat on
or as an individual WG member? 

				Cheers,

				Woj.

				Cheers

				-Sanjay

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

				Sanjay,

				Cheers,

				Woj.

				From: Sanjay Wadhwa

				Woj

				Cheers

				-Sanjay

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

				Hi Folks,

				Regards,

				Woj.

				-Woj.

				It's all simple:

				-Woj.

				Hi Woj,

				thanks,

				Peter

				Hi Folks, 

				Thanks, 
				Woj.

---

From: Peter Arberg <[email-masked]>
Date: Thu, 8 May 2008 16:16:39 -0700

Hi,

I have to say as well that my comment to vote for removal of the Bulk is not
because I do not see value in some optimization, it was for the reason I do
not want to see a non used item delay this draft.

I think we should remove non used items and move the draft forward as
soon as possible, and then open up for new contributions after the base ANCP
specifications have been accepted and documented as a rfc.

cheers,
Peter

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DE CNODDER Stefaan
Sent: 8. maj 2008 12:18
To: Sanjay Wadhwa; Wojciech Dec (wdec); [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message

Hi Sanjay, Woj,

I see some advantages in having bulk messages to optimize ANCP.  However, bulk messages are not the only solution.  It is wrong to discuss bulk messages without comparing it with alternatives.  It looks like a good solution to me but maybe there are better ways in optimizing ANCP.  So far the working group has not been working a lot on optimizations.  According to me, keeping bulk messages in the base spec is wrong and it should be removed.  People are invited to submit solutions to optimize ANCP in the form of a seperate draft, and one such draft could be bulk messages.  Then when the working group decides that it is time to work on optimalisations, the proposed solutions can be compared and discussed.

regards,
Stefaan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sanjay Wadhwa

Inline again [SW2]

-Sanjay

Should have added: Please feel free to put forward a bulk ack proposal to the WG. Just axe the existing bulking text before someone goes starts thinking of actually adopting it.

-Woj.

inline woj#2>

Sanjay,

inline

1. If a sender knows it has a bunch of messages to send (e.g. ANCP adjacency flaps, and all the port-up messages need to re-played), then bulking by definition allows the application to invoke TCP fewer times to transmit everything that it needs to transmit, which in a lot of systems can translate to significant compute and memory efficiency (specially, if we are considering a large amount of state). This is not to say one can't realize this in an implementation specific way.

Woj> Even with bulking one needs to realize the TCP interaction with some thought. Perhaps bulking indeed offers the opportunity for a delveloper to think about that, but I seriously doubt that anyone familar with TCP app development would overlook this aspect in the first place.

[[SW]] I would like to believe it. History doesn't bear this though.

Woj#2> Unless the spec forces Bulking to be used for every single multi-message exchange, the bunching effect will not appear, nor will any optimization.

However, if neeeded, bulking also has the benefit of affording optimized acking (e.g. if no error is encountered in proccessing all the sub-messages in the bundled message, it is possible for the receiver to send a cummulative ack to the sender rather than individual acks).

Woj> A cumulatitive ack would appear to be desirable in some cases, but I see this as very different to the bulk ack currently described which essenatially carries in bulk all of the individal acks. The bulking mechanism is quite clear in saying that each ANCP message is bundled header and all, and acted upon individually by the recipient, and whether it's a request or an ack is secondary. I'm sure you'll agree that this is undesirable overhead and complexity for what it's worth, also in view of the fact that "something" on the recipient side would need to decide what ack/nack goes into a bulk response and what doesn't.
Having a cumulatitive ack is an all thogether different thing, which I would support, and it should not involve the "bulking" of each indivdual ack, and is an item that for which proposals are welcome.
[[SW]] Sorry, I should have been clearer. Bulking adds an overall header for the individual messages being bulked. If all the messages succeed, we can define the behavior to send a single ACK (NOT a bulk ACK composed of individual sub-messages carrying ACK) with the transaction-ID of the main header reflected back in the ACK.  This provides an elegant way to address cumulative ACK. This is not defined in the draft today (see "if needed" above), but is easily provided by bulking, and can be added if we agree.
Far as request message is concerned, having individual messages (with their own header) in the request reduces complexity, provides a way to bulk messages of different types if needed. It allows each sub-message to be individually NACK'd where required. Bulking in such a way allows the flexibility of treating individual sub-messages as completely independent or related.

Woj#2> The above, in principle is fine, BUT it is far removed from the current bulking mechanism. The order would be to have a proposal regarding this on its own right.

[[SW2]] It can easily be extended and doesn't need to be done right away. Rehashing (new proposal) when you have the basis for in the draft is not justifiable.

2. Bulking also provides a nice solution if one ever needed to atomically receive and process *distinct* ANCP message types.

Woj> There appears to be no such thing;
[[SW]] Today, but as you mentioned in another thread, we need to design the protocol to be generic in anticipation of such requirements.

Woj#2> What tentative requirements are you referring to, a relay? If so, bulking doesn't help there. This is also much different from a discussion about a generic TLV format that is to be used by the protocol.

in bulking, presumably the reciever would have to buffer all the way until the end of the bulk message, and then process each message individually. This seems rather overweight when compared to simply sending each message again.
[[SW]] Draft doesn't impose on how much you bulk. If atomicity in handling of bulked messages is warranted by a use-case, then yes you want to get the entire message. If not, you could presumably process as you receive each complete sub-message within the bundle.

Woj#2> Adding a single bulk envelope and sending inside it 100 messages vs 2 bulk envelopes with 50 messages is also pretty pointless, and an exercise in optimizing something that isn't needed in the first place: In each case you're still sending 100 messages! The downside is that in either of the bulked messages case you generally will have to wait till the full message is received. There are betterTCP access

 [[SW2]] Sorry to repeat. If you need atomicity for the sub-messages in the bundle, then you need to wait. If not then you don't have to. This is providing you the flexibility, which you don't easily have with individual messages (e.g atomic handling is hard to realize with individual messages).

What is the downside of having it? It is negotiable as an optional capability.

Woj> A couple of reasons come to the fore; i) no body saw a good reason so far to implement it/use it ii) it's added protocol "stuff" that has no clear benefit, does not realize any new use-case, does not optimize much, and in fact as mentioned above it appears to rather have some downsides such as extra overhead, buffering and delay.

Let's now have the axe fall...
[[SW]] Let us please not be dismissive towards something that has benefits (as outlined above).

Wo#2j>  With the exception of cumulative ack, which does deserve a standalone proposal to be put forward, neither me nor other members of the WG do appear to share the views regarding the purported benefits on bulking, nor a desire to retain it in the spec.
[[SW2]] See above. This has been in the draft for a while, and I have not seen any technical arguments from anyone else on removing it from the draft. I have clearly outlined the benefits above, and don't see convincing technical reasons for this to go.

[[SW2]] Is this with your chair hat on or as an individual WG member?

Cheers,
Woj.

Cheers
-Sanjay

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: Tuesday, May 06, 2008 1:24 PM
To: Sanjay Wadhwa; Peter Arberg; [email-masked]
Subject: RE: [ANCP] Bulk Transaction Message
Sanjay,

can you please present to the WG and myself how bulk transaction capability is useful in any way in terms of scaling for example? And by the way, please treat this discussion is orthogonal to any other.

Cheers,
Woj.

  It is a bad idea to remove bulk-transaction capability from the draft. On one hand you are trying to add "marginally useful" extensions (with TLVs), and on the other hand you are arguing for removing useful abstractions which can help with scaling. If bulk-transaction capability needs to be augmented or modified, then we should consider augmenting it, rather than removing it from the draft.

Cheers
-Sanjay
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Wojciech Dec (wdec)
Sent: Tuesday, May 06, 2008 12:42 PM
To: Peter Arberg; [email-masked]
Subject: Re: [ANCP] Bulk Transaction Message
Hi Folks,

Regards,
Woj.

-Woj.

-Woj.

thanks,
Peter

Hi Folks,

Thanks,
Woj.