Subject: Re: Transport assumptions and "hooks?"

From: Tal Anker <[email-masked]>
Date: Fri, 28 Nov 2003 01:01:09 +0200

Going over the last couple of days messages (of this thread), Joel's email below seems, IMHO, the most reasonable way to go... It seems that this allows for either tcp/udp/reliable-mcast/combination-of-all, which should bring back peace :-)
 
So, if the above is accepted (I do not think I have seen replies to the below message), I guess the requirement draft should be updated?
 
- Tal

	-----Original Message----- 
	From: Joel M. Halpern [mailto:[email-masked]] 
	Sent: Tue 11/25/2003 5:13 PM 
	To: [email-masked] 
	Cc: 
	Subject: Transport assumptions and "hooks?"

	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

---

From: Jon Maloy <[email-masked]>
Date: Thu, 27 Nov 2003 18:04:35 -0500

Difficult to disagree with both of you.
/Jon

---

From: avri <[email-masked]>
Date: Fri, 28 Nov 2003 09:10:40 +0900

I don't see a need to change the requirements to make this happen.  The
requirements, and caveats, already exist for reliability, congestion
control, flow control and security.  So anything that functions within
those constraints should be allowed.

a.

On fredag, nov 28, 2003, at 08:01 Asia/Seoul, Tal Anker wrote:

> Going over the last couple of days messages (of this thread), Joel's
> email below seems, IMHO, the most reasonable way to go... It seems
> that this allows for either tcp/udp/reliable-mcast/combination-of-all,
> which should bring back peace :-)
>
> So, if the above is accepted (I do not think I have seen replies to
> the below message), I guess the requirement draft should be updated?
>
> - Tal
>
>
>
>