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

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

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.

> 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.
 
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). 

This part we can resolve 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?
[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.
>
> 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.

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 16 Mar 2004 07:34:00 -0500

> that's fine...deferred for now.

I think i could say TCP right at this very moment. In other words i dont
think this is a contentious issue. SCTP is another protocol
that meets those requirements. But lets discuss after. This should not
hold us from moving to the next topic.

> mean by semi-reliable multicast...can you explain ? I think reliability,

I was refering to our experiences in using both together.
(BTW, this is also one area we differ slightly).
When a message is to be delivered reliably, CE would send frist on
multicast; when things were fine we received all FE responses on
multicast connection. When things were not fine we didnt receive some
responses from some FEs. In this case we resent on TCP only to those FEs
that failed to respond. There are various reasons why you would resend
on TCP but i dont wannna go into them at the moment. 
Netlink2 can ask for reliability on a per message level. This helps
the underlying transport abstraction decide how to deliver that message.
An Add route for example MUST be reliably delivered whereas some
heartbeats dont have to.
I agree with realibility, congestion control etc being met - but
we could simplify a lot. 

> [HK] That's fine, but this is important in order to use Multicast in an

This could be done in the CEM/FEM plane or negotiated via the CE/FE;
we can decide on the merits later. I am not religious about which one
should be used. My experiences are with CEM/FEM.

> one connection. Is this accurate?

That does seem reasonable to me.
To come back to my note from above: We still differ on some specifics. 
Example we saw value on send-on-multicast-resend-on-unicast. For this 
to be met, the CE or FE should not care which connection it received the
message on. As an example it may receive the hearbeat on 1,2 or 3.
Does this sound reasonable?
 
> [HK] Not sure if I understand this properly...can you explain a bit more

If you say use TIPC or something TIPC-like you probably want it to run
only within the close proximity case. i.e you most likey dont want such
packets to hit a shared network. Same with L2.
You could make TIPC think things are in the same chasis by connecting
several such chasis across multiple hops interconnected maybe by TCP.
This would be like DVMRP "islands" for example in the old mbone days
interconnected using IPIP tunnels. OSPF does similar things.
If you use L2, you could use something like L2VPN. etc.

I have a feeling this maybe a controvesial issue.

cheers,
jamal