|
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
Inline
again
[SW2]
-Sanjay
From: Wojciech
Dec (wdec) [mailto:wdec at cisco.com]
Sent: Wednesday, May 07, 2008 10:47
AM
To: Wojciech Dec (wdec);
Sanjay Wadhwa; Peter Arberg; ancp at ietf.org
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.
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec
(wdec)
Sent: 07 May 2008
16:27
To: Sanjay Wadhwa;
Peter Arberg; ancp at ietf.org
Subject: Re: [ANCP] Bulk Transaction
Message
Sanjay,
inline
woj#2>
From:
Sanjay Wadhwa [mailto:swadhwa at juniper.net]
Sent: 07 May 2008 16:02
To: Wojciech Dec (wdec); Peter Arberg;
ancp at ietf.org
Subject: RE:
[ANCP] Bulk Transaction Message
Woj
Inline
[SW].
From:
Wojciech Dec (wdec) [mailto:wdec at cisco.com]
Sent: Wednesday, May 07, 2008 3:32
AM
To: Sanjay Wadhwa; Peter
Arberg; ancp at ietf.org
Subject: RE: [ANCP] Bulk Transaction
Message
Sanjay,
inline
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.
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.
Sorry, it just
needs 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: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.
|