Subject: Re: Transport assumptions and "hooks?"

From: Alex Audu <[email-masked]>
Date: Mon, 1 Dec 2003 15:49:04 -0600

Sorry if this is taking the list back in time, but I am just catching up with mails.

Clearly, the requirements states that the ForCES protocol should be transport
independent. However, for any transport "X" a solution is based on, the solution
must explain how it plans to meet the ciritical issues of reliability, security, and
other requirements listed in the ForCES requirements document. The requirements
document is comprehensive enough and there is no need to change it at this time.

Regards,
Alex.

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
>
>
>
>
>         -----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: "Putzolu, David" <[email-masked]>
Date: Wed, 3 Dec 2003 08:57:31 -0800

[chair hat on]

The requirements has issued as an RFC, as such, that
document cannot be changed at this point.  If the working 
group wanted to we could create an entirely new 
requirements RFC.  However, it is also possible to come 
to a consensus on the list about some topic and rely on 
that consensus going forward without having to capture 
it in a draft/RFC, as long as the consensus is well 
understood and documented.

Cheers,
David

> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of avri
> Sent: Thursday, November 27, 2003 4:11 PM
> Subject: Re: [FORCES] Transport assumptions and "hooks?"
> 
> 
> 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
> >
> >
> >
> >
> >       multicast support, I realized I was making 
> assumptions about the
> > requirements.
> >       Reading the requirements draft, it is not explicit 
> about certain
> > things.
> >
> >       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
> >       Note that I have found that flow control needs to be 
> thought about
> > even for
> >       in-box solutions.
> >       retransmission.  Without addressing the other 
> elements of the list, I
> > do
> >       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
> >       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
> >
> >
>