Subject: Re: TML data channel transport protocol choice?

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Nov 2005 23:36:24 -0500

Utilizing DCCP means that ForCES at least avoids having its own traffic 
concentration mechanisms cause congestion problems for its own control 
mechanisms.
Yes, TCP can not guarantee its own behavior. But we can assume the net is 
reasonably well behaved.
Our job is to make sure that our protocols match that assumption of being 
well-behaved.

Yours,
Joel M. Halpern

At 10:35 PM 11/1/2005, Wang,Weiming wrote:
>Sorry a mistyping in the message as below.
>
>----- Original Message -----
>From: "Wang,Weiming" <[email-masked]>
>To: <[email-masked]>
>Sent: Wednesday, November 02, 2005 11:30 AM
>Subject: Re: TML data channel transport protocol choice?
>
>
> > I see that, in the multihop TML deployment,  the network is quite possible
>being
> > a publich netowrk, therefore,  only ForCES elements Applying DCCP actually
>also
> > does ganrantee the transport reliability for ForCES PL control message
>
>SHOULD be 'does not garantee'.
>
> > transport, because, others may still possibly use things like UDP which 
> will
> > congest the ForCES TCP still.
> >
> > Therefore, we need to recognize if the defined TML should be specified to a
> > public or a private(leased) network or not.  Moreover,  publich network 
> mostly
> > match the multihop case and private network may mostly match to single hop
>case.
> > As a result, to explicitly specify that a TML is a single hop and for 
> private
>or
> > a multihop for public is a valuble specification.
> >
> > thanks,
> > Weimnig
> >
> > ----- Original Message -----
> > From: "Joel M. Halpern" <[email-masked]>
> > Subject: Re: TML data channel transport protocol choice?
> >
> >
> > > Do we plan to specify that the protocol should operate with TTL set to 1
> > > (i.e. actually enforce closeness?)
> > > If so, then we can look at whether that constraint is good enough.
> > > If not, given that we know real world deployments always stretch teh
> > > envelop, I would be very uncomfortable with taking a path that was only
> > > reliable under such deployments.
> > >
> > > Yours,
> > > Joel
> > >
> > > At 08:34 PM 11/1/2005, Jamal Hadi Salim wrote:
> > > >If one was to say we are restricting the ForCES initial release to a
> > > >single hop; i can see the possibility of UDP as well being a valid
> > > >candidate. Congestion control - given the constraints of a single hop
> > > >(aka close proximity)- should be sufficiently handled via QoS control.
> > > >I am not even thinking of rate control - rather something simple like
> > > >strict priority queuing. Pick best effort for redirect. Queue fills up,
> > > >drop.

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 2 Nov 2005 13:11:48 +0800

This comes to a relatively odd situation.  People can benifits from things like
DCCP only after it has been mandatory to all.  Currently we are still in a pool
full of UDPs. To mandatory DCCP only to ForCES helps less to the pool.
Therefore, unless IETF has a mandatory DCCP for all applications, ForCES is not
necessary to be a respectful pioneer.  We can define a DCCP TML, but that is
just a choise for users.  We should have things like UDP for users who don't
want to be respectful prioneers.

thanks,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 2 Nov 2005 17:23:04 +0800

One more advantage to adopt UDP is its generic support for multicast, which
ForCES can benifit greatly from. Now DCCP only support unicast. We have to
confess that to deploy multicast in a multiple unicast way is only the last
choice for the solution.

Thanks,
Weiming