From: Sanjay
Wadhwa [mailto:swadhwa at juniper.net]
Sent: 07 May 2008 02:03
To: Wojciech Dec (wdec); Peter
Arberg; ancp at ietf.org
Subject: RE: [ANCP] Bulk
Transaction Message
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.
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.
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.
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.
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).
Cheers
-Sanjay
-----Original Message-----
From: Wojciech Dec (wdec)
[mailto:wdec at cisco.com]
Sent: Tuesday, May 06, 2008 1:24
PM
To: Sanjay Wadhwa; Peter Arberg;
ancp at ietf.org
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:swadhwa at juniper.net]
Sent: 06 May 2008 19:08
To: Wojciech Dec (wdec); Peter
Arberg; ancp at ietf.org
Subject: RE: [ANCP] Bulk
Transaction Message
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.
-----Original Message-----
From: ancp-bounces at ietf.org
[mailto:ancp-bounces at ietf.org]On Behalf Of Wojciech
Dec (wdec)
Sent: Tuesday, May 06, 2008 12:42
PM
To: Peter Arberg; ancp at ietf.org
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:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 20 April 2008 15:18
To: Peter Arberg; ancp at ietf.org
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:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 20 April 2008 14:39
To: Peter Arberg; ancp at ietf.org
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:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Peter Arberg
Sent: 19 April 2008 03:07
To: Wojciech Dec (wdec);
ancp at ietf.org
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:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 18. april 2008 08:04
To: ancp at ietf.org
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.