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

From: "Putzolu, David" <[email-masked]>
Date: Fri, 19 Mar 2004 13:37:19 -0800

Hi Alex - my response inline.

Alex wrote>
> 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.

I was using wire as a virtual connection of sorts with certain
levels of service associated with it.  The underlying TML could
then be defined to use SCTP streams for different wires maybe?

However, main point is to first define the services the FP layer
needs from the abstract TML, then each TML spec would decide
how to achieve those services.  TCP was just an example of what
the IP TML might choose, SCTP is definitely another alternative.

Alex wrote>
> 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.

Having a PL <-> PL heartbeat, to make sure the PL is alive,
makes sense.  I agree that this is separate from TML liveness.

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

I agree that it is for the TML to implement reliability,
not the PL. The PL simply will define the abstract TML
requirements, i.e. that all TML implementations must
provide channels with certain reliability characteristics.

I agree with your and Jon's point that implementing
a reliable connection is non-trivial.  TIPC has done 
this I think. 

> 2) There is something called IPover Ethernet (IPoE),..and this may be 
> leveraged here.
>      It will save us from running directly over ethernet.

If we use IP we are right back with being forced to use
SCTP, TCP, DCCP, etc.  We then have no choice: If IP packets
are being exchanged, what runs over them must be a RFC2914
congestion aware transport - which is why I was proposing
getting away from IP in the very close scenario.

Cheers,
David

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

---

From: Jon Maloy <[email-masked]>
Date: Fri, 19 Mar 2004 18:00:03 -0500

/jon

Putzolu, David wrote:

Alex wrote>

suggest we 

use streams instead.

This can be done, but we are stuck with the same limitation as with TCP:
all streams have the same properties, and can not be given individual
characteristics such as congestion priorities.

Alex wrote>

removed 

isolation.

  

Both are needed, but the PL supervision can (and should be) made much
more selective, i.e. the heartbeat frequency must be set depending on
the importance of the user.  We are talking about potentally hundreds
of nodes here, and having multiple-level heartbeats on multiple
connections
between each CE and all FE:s, which I assume is a realistic scenario,
may
easily amount to a significant background load. There is an example in
my draft where I calculate  the background load for supervising a
2000-node 
cluster, and this shows that this algorithm must be designed with great
care, 
and preferrably made hierarchical.

this I think. 

leveraged here.

Agree. The options are  SCTP, TCP, DCCP, and/or a non-IP protocol.
So, if we want something better than the available IP-protocols can
provide,
we must have at least one non-IP alternative. (And let me repeat, TIPC
can
also be carried efficiently over these three IP-protocols, so it is in
reality 
the only TML we need)

Cheers,

David

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/forces-protocol
<https://www1.ietf.org/mailman/listinfo/forces-protocol> 

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: 19 Mar 2004 20:56:40 -0500

On Fri, 2004-03-19 at 18:00, Jon Maloy wrote:

[..]
> There is an example in
> cluster, and this shows that this algorithm must be designed with
> great care, 

Protocols like MBUS have some interesting tricks.
  http://www.ietf.org/rfc/rfc3259.txt
Look at section 8.1.1
We adopted that algorithm

> Agree.

Sorry, folks - I would have to disagree. 
There could be a TML which is very simple and based on just TCP
and UDP. 
It is upto the TML to take care of the reliability, cc, etc.
CC MUST emulate RFC2914 if not running over RFC2914 capable protocol;
perhaps borrowing some of the algorithms from DCCP would not be a bad
idea if DCCP is not ready.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Mon, 22 Mar 2004 12:17:15 -0600

Hello Jon,

One way to reduce the heartbeat overhead is to NOT do it if traffic is 
being sent between
CE and FE in question successfully. So, you only send heartbeat when 
channel has been
idle for a while (some preset time span).  I think this is also goes 
with your selective
heartbeat  notion.

Regards,
Alex.

Jon Maloy wrote:

>>[snip..]  
>>  [snip..]
>>>    removed connectivity. This helps ensure the PL is not off in the weeds or or crashed while the transport is fine.  It also helps problem  isolation.
>>>[David]
>>>[/David]
> between each CE and all FE:s, which I assume is a realistic scenario, may