Brian E Carpenter <[email protected]> wrote: > (1) Flooding (M_FLOOD) messages. These are UDP multicasts, so in effect > all nodes must agree on the same maximum size. To send messages above > the present limit, the maximum flood message size would have to be > increased everywhere in the autonomic network. That is trivial if we > allow operator configuration, but since an AN should be self-creating, > we want to avoid operator configuration. Therefore, we need GRASP to be > able to self-configure this.
For the flooded messages over UDP, it seems unwise to ever assume we can
reliably get more than 1280 through. In production, this goes over IPsec ESP
tunnels.
At some point, we probably should specify use of
IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP
Traffic Flow Security
draft-ietf-ipsecme-iptfs-09
This would provide a better fragmentation regime than what we do now, and
there maybe some traffic analysis and predictability advantages here.
(If ACP traffic *always* takes 1% of bandwidth, it becomes more predictable,
but also there may be congestion advantages to having "reserved" that bandwidth)
> (2) Unicast messages (discovery responses, synchronization,
> negotiation). On investigation, it is very easy to allow such messages
> over TCP to be of any reasonable length, with no protocol change and
> without all nodes necessarily agreeing on what a "reasonable length"
> is. I discovered that my demo implementation of GRASP would already
> handle messages up to 4096 bytes, and tweaked the code to remove that
> limitation. I tested it with a GRASP objective exceeding 5000 bytes.
For the messages over TCP, which in response to a UDP flooded or discovery
message, the discovering node can announce it's ability to receive bigger
messages (and the size).
In the Discovery Response Message, the discovered node could initiate it's
maximum too.
How to fit this into the messages, I don't know yet.
It's not clear me that we need to do this network-wide, but we could do that.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
