Subject: RE: [Forces-protocol] Issue 3:Transport/Unicast/Multicast/Broadcast

From: [email-masked]
Date: Tue, 16 Mar 2004 06:26:45 -0500

Hello Jamal, Hormuzd,

Comment are inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Khosravi,
> Hormuzd M
> Sent: Tuesday, March 16, 2004 1:16 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Forces-protocol] Issue
> 3:Transport/Unicast/Multicast/Broadcast
> 
> 
> Hi Jamal
> 
> Thanks for your comments. In general, I am fine with them, 
> will make the
> necessary changes. See more comments below...
> 
> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> > Furthermore, in case of IP this will be a TCP connection between the
> CE
> > and FEs. 
> 
> Lets not say TCP or SCTP at this point; defer this to later.
> [HK] I thought all of us used TCP so we would easily agree on 
> this...but
> that's fine...deferred for now.

We are defering one issue after another. We should try to close one issue after another. 

For unicast its much straightforward choice. As TCP is widely deployed we should opt for TCP.
If we strong compelling reasons for not having TCP that should be explicitly discussed.

IMHO we should try to close each issue rather than deferring.

> 
> > In addition to this, in case of 'close proximity' between the
> > CEs and FEs And in case the interconnect between them supports
> > multicast, the CEs and FEs Should/Must also establish reliable,
> 
> Why the should?
> [HK] I didn't want to get into a debate between Should/Must, 
> therefore I
> put both. Personally I am fine with a Must.

must would appropriate here.

>  
> I personally dont think that a single multicast connection would
> be an efficient thing for a transport. On the same token i dont
> think a single unicast connection would be efficient.
> If you have a reliable unicast connection, i see the value
> of having a semi-reliable multicast connection - at least based on our
> experiences. Maybe people with other experiences can share.
> 
> [HK] Based on our experiences and customer requirements, we have been
> able to satisfy them with 2 unicast connections. I am not 
> sure what you
> mean by semi-reliable multicast...can you explain ? I think 
> reliability,
> CC is important for unicast or multicast if it is used to transport
> control messages...based on requirements and all the 
> discussions that we
> have had on the ForCES list on this topic.
> 
> > congestion aware Multicast connections. The establishment and
> semantics
> > of these Multicast connections is negotiated during the
> > binding/capability discovery phase in the ForCES protocol
> > (post-association). 

Congestion aware multicast connection ??? Looks like Forces protocol needs to implement many things here...
Do we have already some RFC to support this function?

> 
> This part we can resolve later.

Let us summary and then we see whether we want to defer later.

> [HK] That's fine, but this is important in order to use 
> Multicast in an
> efficient way.
> 
> > For example, the CE and subset of FEs might
> > negotiate on establishing a Multicast connection for 
> communication of
> > IPv4 LFB attributes. These reliable, congestion aware 
> connections will
> > be used to communicate the control messages outlined in RFC 3654
> > (section 6, #6c). (For data messages such as those outlined in RFC
> 3654
> > (section 6, #6b), the ForCES protocol Must/Should also support an
> > un-reliable but congestion aware Unicast connection between 
> the CE and
> > FEs.- we can defer on this one till we come back to issue#2)
> 
> So three classes of connections:
> 1) totaly reliable unicast
> 2) probably a range of unreliable, semi-reliable to reliable multicast
> 3) unreliable UDP-like unicast for data redirection.
> 
> You also seem to be stating for 2) above you could have more than
> one connection. Is this accurate?

What is the meaning of semi-reliablie here?

> [HK] Perfect !
>  
> > Here are the basic ForCES Impl Categories...
> > 
> > Cat 1: Local (inside box) with reliable,CC multicast 
> support (Example,
> > ATM fabric backplane)
> > No need of IP in this case, ForCES can directly run over L2 or use
> > something like TIPC.
> > Unicast+ multicast connections can be used in this case for
> > communication.
> >

The statement is not clear to me... 
Are we recommending that for single box its non-ip. There are systems that uses IPv6 and also IPv4 within single box...
they have unicast mechanism. 

May be we should have something like this.... for non-IP interconnects (with in single box) we can use 
the proposed mechanism....

> > Cat 2: Local with No reliable,CC multicast support (Example,
> > Gig-Ethernet backplane)
> > No need of IP in this case, ForCES can directly run over L2 or use
> > something like TIPC.
> > Unicast connections can be used in this case for communication.

The above two statement make a case for non-IP interconnects. We should also consider the case for IP interconnect with single box.

> > 
> > Cat 3: Non-local (Example, Ethernet wire)
> > ForCES runs over IP/transport protocols in this case.
> > Unicast connections such as TCP, DCCP can be used in this case.
> 
Here we should also consider non-IP physical box. for example ..... distributed GGSN (or SSGN) connected via l2 swichtes in wireless interconnect
....

Regards
Ramg

> I dont think we should say "no need for IP" but rather we can run
> without IP. 
> [HK] Fine.
> 
> Additionaly i think that there would be demarcations between close
> and non-close proximity where other protocols such as TIPC or 
> L2 direct
> maybe constrained. There may be tunnels of sorts connecting
> such demarcations to create a large NE.
> [HK] Not sure if I understand this properly...can you explain 
> a bit more
> ?
> 
> 
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Jamal Hadi Salim <[email-masked]>
Date: 16 Mar 2004 08:12:22 -0500

Ram,

> We are defering one issue after another. We should try to close one issue 

We have to at least see some direction for this first phase.
i.e not to agree 100% but say we could resolve later.
When we get to details we MUST close the issues.
Example the issue of TCP vs SCTP is not gating in my opinion.

cheers,
jamal