Subject: [Forces-protocol] Issue 2: Multiple channels/connections

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Mar 2004 12:06:17 +0800

Hi, all

I don't know why it suddenly becomes so silent here. To try to speed up the
process, pls allow me to activate the Issue 2. I know Hormuzd may be writing
something, it just does not conflict.

This issue has in fact been quite largely discussed. I (suppose Jamal also )
think what we need to do now is just to find more reasons for such arrangement.

Our team idea is:

1. The idea to distinguish the Control packets from Data packets to have them
able to be differently processed is very useful for DoS protection as well as
for achieving different transport reliability, therefore it MUST be included in
ForCES protocol.

2. It seems no use (I suppose Jamal says little use) for us to protect DoS by
stretching out such distinguish to physical link (that is to setup two different
channels for the two kinds of packets), therefore, it should not be described as
a kind of DoS protection means in the protocol.

3. To setup two different channels to achieve different reliability may be
practical, but it should not be described as a MUST item in the protocol,
instead a "RECOMMEND" is better. This is because we must consider that we have
already required the ForCES protocol SHOULD be able to support multiple
interconnections, and in some interconnections like some backplanes (we should
allow many kinds of backplane connections), we are actually not very sure if a
separate channel is available or how it is separated. Actually currently, we
only know that over IP network, UDP and TCP can be used for such separation. We
also don't have to explicitly list how such separation is implemented. On the
other hand, not to use lower reliability channel for Data packet transport
actually does not harm too much. As a result, we suggest the protocol
description may be look like "If available at transport layer, ForCES protocol
RECOMMENS to use two different channels with different reliability to transport
Control packets and Data packets, with the lower reliability channel assigned to
Data packet, so as to save system resources and improve the Control channel
transport performance.

Any thoughts?

Yours,
Weiming

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Mar 2004 06:57:11 -0500

> think what we need to do now is just to find more reasons for such arrangement.

Correct, my view was a) need to describe the characterization of the
channels b) need to describe when/why multiple channels would be needed.
Let me read on you email first (and thanks for taking the effort to
write this up).

> for achieving different transport reliability, therefore it MUST be included in

For DoS:
Do you see anything extra in the headers other than what has been
discussed already? If yes, can you explain? My view described earlier:
a) The forces header as discussed already should be sufficient to
describe the packet contents i.e based on the header you should be able
to tell if the packet is data or control.
b) We have the 3 bit priority field for this to protect at the
application level.
c) At the L2/3 we have either diffserv or 802.1p etc
d) At the physical link we can either have two or more separate physical
links or an example idea mentioned previously have several DMA channels
to distinguish between the different levels of priority.
e) per flow ingress scheduling of some form which may involve rate
limiting.

b) is the only binding issue. The rest are either implementation or
administrative configuration issue. Infact one could argue since we
provide the mechanism even b) falls under the same category.

> a kind of DoS protection means in the protocol.

I agree. At least not for DOS purposes. 
I will chop this email here for readability.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Mar 2004 07:25:33 -0500

> Data packet, so as to save system resources and improve the Control channel

I am in general agreeement with you i.e cannot mandate that hardware be
built with multiple channels. At least this will rule out a _lot_ of
legacy existing hardware (which i think will benefit from ForCES).
Maybe the first step is to to define what "channel" is. Is it fair to
say that it is strictly a link/physical link ONLY?
There maybe "sessions" on each "channel". But if one of the sessions is
freely DoSing the link, then it may fill it up in which case the
separation is of no value.
This brings me to what i said earlier:

a) What are the different characteristics of each channel/session? I see
them defined in terms of reliability, cost, latency and throughput.
Is there an attribute thats missing?

b) When do you use a channel/session?
This is a policy issue - but needs to be decided for the protocol to be
simple. In our implementation we had two types of sessions all over one
physical channel. Our major policy was based on strictly cost.
There was always a TCP connection between each FE to one or more CEs.
There was at least one multicast connection. Both were reliable; and
had the same throughput and latency characteristics.
>From a CE, the TCP connection was more costly because a send to all FEs
requires a replicast. OTOH, a single message was sent to all FEs using
multicast. So always send on the multicast first.
Retransmits on the multicast session are expensive on the FE side
because some FEs which have already received the message now receive it
a second time.

As you can see, we did not need to separate into C and D channels.

I have a feeling theres some fundamental thing i am missing with
this desire to separate C and D (other than an academic one which i
mostly ignore).

cheers,
jamal