Subject: [Forces-protocol] Unicast/Multicast/Broadcast and AD stance & use of TCP/SCTP/UDP/IP in ForCES

From: "Putzolu, David" <[email-masked]>
Date: Thu, 18 Mar 2004 15:33:20 -0800

Hi all.

Just a small clarification on the reliability and
congestion control discussion based on what several
ADs told me in Korea in no uncertain terms.

Any IP-based implementation of ForCES will be forced 
to use a RFC2914-compliant transport for all its 
packets.  That pretty much disallows use of UDP at 
all in the ForCESoverIP case and leaves TCP, SCTP,
and possible RMT as the only transports ForCES can
use over IP.

Both myself and Jon Maloy pushed back on this, saying
that one might want to use UDP in a purely local
scenario for various reasons.  The ADs where adamant,
arguing that one can never guarantee that IP will
stay local, and the IETF would not standardize 
using a non-2914 compliant IP protocol (e.g. UDP).
The ADs pointed to iSCSI as a precedent.

This isn't to say that multicast cannot be used - I
am a fan of the transport abstraction approach that
says that the ForCES protocol will just assume it has
a  multicast transport and a unicast transport, and
that the transport layer mapping ala GSMP will take
care of it.

Below is a URL to some text and drawings based on Alex 
and other's comments - what do you think? Is this an
acceptable solution to transport/multicast/unicast/
retransmit/etc.?

http://www.sstanamera.com/~forces/proto/ForCESLayered.htm

-David

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

---

From: Jon Maloy <[email-masked]>
Date: Thu, 18 Mar 2004 20:42:51 -0500

This looks very reasonable.
I still have some questions: Will the TML be presenting one
uniform API towards the protocol layer ? If so, what are we going
to do when the protocols have different address formats, and even
completely different address abstractions ? Do we invent our own
address format and model, as a least common denominator of the
used transports ?

We probably need only three types of addresses:

1: An opaque unicast address that is mapped down to an Ip-address/port
tuple, an ethernet address, or a TIPC port name, depending on transport.

2: A multicast address that is mapped down to ditto addresses in
    the different transports.

3: A "multicast group" abstraction that is mapped down to multicast
   group addresses on IP, Ethernet, or a port name sequence on TIPC.

With TIPC, it will somewhat reduce the flexibility of the port name
sequence concept, which makes it possible for the CE:s to define
"multicast groups for the occasion", but it should be easily mappable
to a more static multicast group concept, if this is sufficient.

As David stated, the TML layer for L2 would be virtually empty
if mapped down to TIPC, and would give us an early available
implementation of ForCES over L2. Speaking from experience,
implementing a stable and performant transport layer with retransmission,
node- and process supervision, media load sharing and failover etc, not 
to speak
about reliable multicast,  is far from trivial, and we may risk to never 
see
such a protocol come into existence  => we would be confined to TCP, SCTP
and the properties those protocols can offer.

Cheers /jon

>http://www.sstanamera.com/~forces/proto/ForCESLayered.htm

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 18 Mar 2004 21:32:59 -0500

On Thu, 2004-03-18 at 18:33, Putzolu, David wrote:
> all in the ForCESoverIP case 

huh? DCCP aka UDP with CC built in? We could select
different CC algos depending on the scope being used.

> and leaves TCP, SCTP,

Is there a draft/RFC which talks transport layer mapping 
at GSMP level?

> http://www.sstanamera.com/~forces/proto/ForCESLayered.htm

I will study this some more and give better responses.
>From the outset it does look reasonable. I am assuming that
the TML serializes the data to the Forces PL?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 18 Mar 2004 23:00:05 -0500

I looked a little more at the URL posted and i think it is a very good
start; things need to be fleshed out still but we can start from there.

On Thu, 2004-03-18 at 20:42, Jon Maloy wrote:
> uniform API towards the protocol layer ? 

I would think so.

> If so, what are we going to do when the protocols have different 
> address formats, and even
> completely different address abstractions ? 

Shouldnt we only care about the Forces address (aka ID which was hotly
debated a while back)?
Underneath whatever the TML layer does in terms of addressing
should be transparent to the PL.

> Do we invent our own

Refer to note above.

>    group addresses on IP, Ethernet, or a port name sequence on TIPC.

This brings back the notion of IDs we discussed in issue #0.
We have all addressing abstractions of the types you refer to above.

> and the properties those protocols can offer.

Agreed. 
The TML should take care of reliability, congestion control,
availability/failover; interfacing to xEM  etc.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 19 Mar 2004 22:49:32 +0800

Hi David,

From the GRMP design idea, we can not agree on the idea of PL and TML any more.
Of course, we need to have much more discussions on kinds of TML specifications.
Just one comment put inline.
Thank you.

Weiming

----- Original Message -----
From: "Putzolu, David" <[email-masked]>

Hi all.

[Weiming] I just presumptously wonder if iSCSI might have some speed improvement
when a UDP+built-in reliability scheme were also adpoted.

-David

---

From: Alex Audu <[email-masked]>
Date: Fri, 19 Mar 2004 13:36:17 -0600

The PL over TML is a workable model.  My concern is the wire concept 
plays well with
TCP, but I am not sure it does so with SCTP.  I suggest we use streams 
instead.
Also, the liveness checking by TML can only guarrantee the 
TML->transport->peerTML
connectivity.  To make sure PL is in the loop, PL should have its own 
scheme (e.g. ACKs,
heartbeat,..).  That checks the PL->TML->transport->peerTML->peerPL 
connectivity.
This helps ensure the PL is not off in the weeds or removed or crashed 
while the transport
is fine.  It also helps problem isolation.
 
It should be noted also that:
1) the burden rests on TML to implement some reliability scheme in case 
of unreliable
     transport.  This is a tall order. It amounts to re-inventing TCP on 
this layer.
2) There is something called IPover Ethernet (IPoE),..and this may be 
leveraged here.
     It will save us from running directly over ethernet.

Regards,
Alex.