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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 15 Mar 2004 18:15:38 -0800

Jamal, Thanks for the clarification.

Here is some text around this issue which I think is a reasonable
compromise,

All ForCES protocol implementations, MUST support a reliable, congestion
aware Unicast method of communication between the CEs and the FEs.
Furthermore, in case of IP this will be a TCP connection between the CE
and FEs. 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,
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). 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)

In this text I have tried to accommodate the different approaches of
netlink2, GRMP and FACT, at the same time I have made the text strong by
using Must/Should to have easy interop. Let me explain this further...

Netlink2-uses 1 TCP + 1 Multicast UDP connection
FACT-uses 1 TCP+ 1 unicast UDP+CC/DCCP like connection
GRMP-uses 1 TCP+ 1 UDP(in some experiments)...also implemented with only
TCP.

Pls correct me if I am wrong here. The above text tries to accommodate
all these approaches as well as the different scenarios or categories in
which they are applicable.

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.

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.

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.

Let me know what you guys think ?

Regards
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

On Mon, 2004-03-15 at 15:42, Khosravi, Hormuzd M wrote:
> Jamal
> 
> There are a few things which I would like to get clarified from you...
> 
> Are you opposed to having a differentiation on IP basis, rather than
> 'close proximity' ? The Ads seemed to be suggesting a differentiation
on
> IP basis which is different from what you have stated below. 

I actually dont want to restrict to just IP.
Ethernet, TIPC over X, etc. It makes sense to use multicast on
]close proximity to avoid a lot of complexities that are 
seen when you need to maintain state on routers across 
a large network.

> Are you suggesting that Only Multicast must be used in certain cases ?
> or is it Unicast + Multicast if interconnect support both else only
> Unicast ?

More of "if available" MUST be used. So if multicast is available,
use it. I would think Unicast is always available.
This is very similar to what OSPF does.

> From what I have read in your emails, for netlink2 you have used both
> Unicast and Multicast, not just multicast but I just want to confirm
> this.

Yes we used both.
TCP on one connection and multicast UDP on another.
CE transmitted on udp/multicast and retransmitted on TCP.
Our metric was COST in both bandwidth and CPU.
You send one message onto all FEs if you use Multicast; saving on both 
CPU and b/width and then you retransmit only on unicast (TCP) because
there is no point for other FEs which have ACKed to see the message
again and ACK it again

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 15 Mar 2004 22:36:02 -0500

Hi Hormuzd,

On Mon, 2004-03-15 at 21:15, Khosravi, Hormuzd M wrote:
[..]

> aware Unicast method of communication between the CEs and the FEs.

sure.

> and FEs. 

Lets not say TCP or SCTP at this point; defer this to later.

> In addition to this, in case of 'close proximity' between the

Why the should? 
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.

> (post-association). 

This part we can resolve later.

> For example, the CE and subset of FEs might

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?
 
> Netlink2-uses 1 TCP + 1 Multicast UDP connection

Just to clarify: We have the concept of wires; you could put as many
connections as you want negotiated via FEM/CEM interface.
In practice though what we found was we 80-90% of the time used only
the multicast UDP and unicast TCP.

> Unicast connections such as TCP, DCCP can be used in this case.

I dont think we should say "no need for IP" but rather we can run without IP. 
IT should be noted that the close proximity is more than a chasis
and could be chasis or next room closeness.

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.

cheers,
jamal