Subject: Transport assumptions and "hooks?"

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Nov 2003 10:13:12 -0500

In reading (and probably accidentally inflaming) the discussion of
multicast support, I realized I was making assumptions about the requirements.
Reading the requirements draft, it is not explicit about certain things.

A lot of my concerns about multicast are driven by my believe that any
transport we specify must support
1) reliability (specified explicitly in the requirements draft, and
provided by all proposals one way or another)
2) congestion control (explicitly required when there is more than one "hop")
3) flow control (I have been severely burned by assuming I did not need
flow control in my control protocols.  You can get amazing messes if the CE
can overrun the FE, or the reverse.)
4) security (required, with an out for "in-box")

Note that I have found that flow control needs to be thought about even for
in-box solutions.
Some folks have asked that we allow multicast over UDP, with app level
retransmission.  Without addressing the other elements of the list, I do
nto believe that this is a sensible solution for us to allow.
And allowing those other elements adds a great deal of complexity.

There are some cases where multicast would be nice to have.  Hooks which do
not compromise the soundness of the protocol, and which allow for multicast
to be added easily later make sense.
So we probably should allow for multiple simultaneous transports.
We probably should make sure messages include sending and receiving entity
identification.
We probably want to make the identifier space big / structured enough taht
we can add various kinds of logical / multi-entity identifiers in the future.

Yours,
Joel M. Halpern