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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 11 Mar 2004 23:32:02 -0800

Weiming,

Unfortunately, I strongly disagree with #3 below, you keep pushing on
this inspite of several good reasons pointed out my most of the folks
including David's discussion with the Ads. I am not opposed to
recommending some of the packet scheduling schemes that have been
described in GRMP, however I believe we need separate D&C
channels/connections and might actually want to have optional multicast
connections as well for the C channel/connection, in addition to
unicast.

I will send out text on this over the weekend, but if you keep pushing
against having 2 connections, it will be difficult to reach a merger.

Regards 
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: Thursday, March 11, 2004 8:06 PM
To: [email-masked]
Subject: [Forces-protocol] Issue 2: Multiple channels/connections

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: [email-masked]
Date: Fri, 12 Mar 2004 16:54:44 +0900

Hi,

I guess I am confused.  Hormuzd, are you saying that it is critical to 
you that use of 2 channels is a MUST even in a system that does not 
support multiple channels?

As I read Weiming's suggestion, it was that one SHOULD use multiple 
channels in IP systems where they are available.  On the very close 
systems in a box, where multiple physical channels may not be 
available, it doesn't seem to make sense to require their use.

a.

---

From: [email-masked]
Date: Fri, 12 Mar 2004 20:28:08 +0900

Hi,

Never being one to do something just because the AD's are in favor it, 
I thought about this some more.

While I totally agree that multiple channels can often be useful and 
MAY or even SHOULD be deployed where possible, I just cannot wrap my 
mind around the assertion that they are necessary either for DOS 
defense or for giving control messages priority on a busy link.

Perhaps I have been living with and arguing in favor of the fate 
sharing Internet for too long.  And I have seen all sorts of solutions 
for giving  routing protocol messages priority even when data and 
routing protocols where traveling on the same network link, which is 
sort of the normal case.  I don't understand why ForCES would be any 
different.  I certainly believe that there MUST be a way to prioritize, 
and identify C traffic from D traffic I just can't see why it must be 
done one particular way; i.e. separate channels.

a.

---

From: [email-masked]
Date: Sat, 13 Mar 2004 00:35:05 +0800

Hormuzd,

I have to say your reply is really out of my estimation. I thought you might 
have arguement on #2 and an agreement on #3 could be quickly reached after some 
comments and modification. Because you have not presented in your reply, I 
actually don't know what is it that makes you strongly disagree.

To be hornest, I have got a feeling that you might have thought we are "keeping 
pushing on something" just to oppose FACT. That's really a big misunderstanding 
between us. From my past posts and also from the direct talk between us, I have 
for several times mentioned that I think FACT has already contributed to DoS 
protection by proposing the idea to separately process the C and D. What we are 
doing is to perfect the idea and to discuss how it can be better performed. We
(GRMP team) respect this idea. We are not specifically pushing something 
against this idea.

I have also mentioned in our talk that we(GRMP) are ready to give up to accept 
the idea of multipul channels (with its purpose not for DoS). Actually #3 is 
that we think a compromise. 

Although it is our desire to participate in IETF work and we sincerely hope the 
merge could be successful, as a scientist, I have to say we will more desire to 
obey the truth we believe, we just can not give it up to achieve others even 
though the others are very attractive. 

I hope my explanation can help in some way for us to mutually understand more.

Sincerely,
Weiming

> against having 2 connections, it will be difficult to reach a merger.

-------------------------------------------------
This mail sent through HUCNIC Webmail system.

---

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

Guys,

The goal is to have a NEW protocol. The protocol is NOT Netlink2, NOT
GRMP and NOT FACT. At least thats the approach i have been taking[1].
The goal is also to share most importantly experiences. Nothing (at
least at the IETF) is as important as an experience (the "we believe in
running code" part). This also does not rule out good ideas that havent
been implemented in my view.
Weiming, I respect your approach to be technically correct first, but
understand that there may be More Than One Way To Do It(tm) - all of
which could be True(tm). 
Hormuzd: to be fair to Weiming, you did make a very strong statement
without substantiating it. I know we have had discussions on the topic
so far, but lets recall some of the points made so we can move on.
Please repost your arguements.

To make it even more interesting i dont agree with either of you on the
need for C and D channels ;-> I posted my reasoning and experiences
earlier.

Can we have the discussion back on track and close it?

cheers,
jamal

[1]Look at what we have agreed to and compare with netlink2 and you can
see how they differ.

---

From: Alex Audu <[email-masked]>
Date: Fri, 12 Mar 2004 15:44:31 -0600

Hello Avri,

No doubt, the separation of the control packets from data packets that 
STP (Signal
Transfer Points) affords TDM networks is the core reason why TDM 
networks are
far more secure that IP networks. 

Since ForCES allows us to Separate control element from Forwarding 
element over
space, then if we can carry control signals from C to FE over a separate 
channel from
the one carrying user data (hellos,  link state packts, etc),  we can 
surely improve the
chance of the NE surviving a D flooding attack.

Som have argued that you can carry both C/D packets on the same channel, 
but assign
different priorities to them. Well,..doing this doesn't buy one much if 
you have a million
D packets choking up the channel.  So, a separate channel is definitely 
desirable.

We can make using  separate D/C channels as a SHOULD strength (with 
conditions). 
But what is the implication of that on  interoperable secure operation?  
If different vendors
make C and FE boxes, the chance that one would support separate C/D 
channels while the
other doesn't is greater.  That will force the C/FE inter-action to fall 
back on the less secure
single channel model.  I am not sure that is  a  desireable solution 
given the increased attention
on security these days.

Regards,
Alex.

[email-masked] wrote:

> different.  I certainly believe that there MUST be a way to 
> prioritize, and identify C traffic from D traffic I just can't see why 
> it must be done one particular way; i.e. separate channels.
>
> a.
>
>

---

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

/jon

Alex Audu wrote:

> space, then if we can carry control signals from C to FE over a 
> separate channel from

Agree.

>
>
> Som have argued that you can carry both C/D packets on the same 
> channel, but assign
> different priorities to them. Well,..doing this doesn't buy one much 
> if you have a million
> D packets choking up the channel.  So, a separate channel is 
> definitely desirable. 

That depends on where you handle the congestion for D-packets. In a 
sending FE one can check
for congestion front up, i.e. already  in the send operation, and low 
priority D-packets marked as
droppable may be thrown away  instead of being added to the send queue. 
Those packets will
never choke any media or router.
Separate logical channels, i.e. connections with different priorities, 
and where some even
 are marked as  unreliable, is definitely needed, but that does not 
imply there is a need
for a different  physical channel, or indeed different protocols (UDP vs 
TCP) to
handle them.
It is only  a matter of proper handling of priorities, and doing it at 
the right level: For IP
protocols, one can add a simple sliding window (a "sent" and an "acked" 
counter, and a fairly
big send window) at the ForcCES protocol level (we can not reach the TCP 
window, and
UDP has none).  High priority connections have an infinite window, low 
priority senders
drop the packets when the window is full, instead of sending them. (With 
 TIPC, a similar
mechanism is built in.)

> We can make using  separate D/C channels as a SHOULD strength (with 

A MUST would imply that we think other solutions are impossible, and 
would force
vendors to add functionality they may consider unecessary.

> But what is the implication of that on  interoperable secure 
> operation?  If different vendors
> other doesn't is greater.  That will force the C/FE inter-action to 
> fall back on the less secure
> single channel model. 

Less reliable, yes, but why less secure ?

> I am not sure that is  a  desireable solution given the increased 
> attention
> on security these days. 

>
>
> Regards,
> Alex.
>
> [email-masked] wrote:
>
>> Hi,
>>
>> Never being one to do something just because the AD's are in favor 
>> it, I thought about this some more.
>>
>> sharing Internet for too long.  And I have seen all sorts of 
>> solutions for giving  routing protocol messages priority even when 
>> data and routing protocols where traveling on the same network link, 
>> which is sort of the normal case.  I don't understand why ForCES 
>> would be any different.  I certainly believe that there MUST be a way 
>> to prioritize, and identify C traffic from D traffic I just can't see 
>> why it must be done one particular way; i.e. separate channels.
>>
>> a.
>>
>>

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.