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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 14 Mar 2004 22:06:45 -0800

Weiming,

After going thru all the emails, I am still trying to understand why you
are opposed to having separate D&C connections using different
transports as a MUST for IP ? Do you see some harm if we mandate this
for IP ?

I understand your reasoning below for non-IP situation and the answer to
that might depend on what we decide to do for that case when ForCES is
directly running over L2. But other than that, even you agree that
separate C&D connections SHOULD be used for IP case. Does changing the
SHOULD to a MUST break something ? I think using stronger language in
the protocol is helpful for interop. Do you agree ?

The only thing that you disagree on is that using separate connections
is useful for DoS and that is because of the results of your
experimentation. This is very understandable to me, however you must
recognize that a) there are other good reasons for having this b) your
experiments were based on TCP for C channel and UDP for D channel and
clearly I don't think UDP without some form of CC (at app level) is very
useful for the D channel.

I am Not trying to say that your experimental results are incorrect or
you didn't conduct the right experiments...all I am saying is that,
other than the DoS issue I don't think we are disagreeing on anything
else...pls correct me if I am missing something here. If that is the
case, then why are we spending so many cycles debating this issue ?

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

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

---

From: [email-masked]
Date: Tue, 16 Mar 2004 03:08:06 +0800

Hormuzd,

To be honest, your email has put me to a quite upset corner. From one side, I 
just can not find new reasons that can persuade me to believe this is vital for 
ForCES protocol so that it should use 'MUST'. From the other side, I don't want
to let you have a feeling that I am 'pushing on something again and 
again'(though I have much to say), and moreover, it's only a few days before 
20th (as you said, to save cycles). You should notice that what I post for 
discussion as 'RECOMMEND' has already been considered as a possible compromise 
among the different views of previous discussions. Actually when I check recent 
emails and also your newly posted reasons, I have a strong feeling that a 
word 'MAY' is the best to fit the case. You may also notice that it is not only 
I who is objective. 

You may ask why I can either go along with 'NONE', 'MAY' or 'RECOMMEND', it is 
just like that someone wants to give you something but you think the thing is 
actually not vitally needed.

Since the discussion began, I have a feeling that when we meet things that we 
can not agree on which is better, being ready to give up something is vitally 
needed. I think I have done like this, I also appreciate Jamal has done like 
this. In fact, the 'RECOMMEND' and even the 'MAY' has been very close to what 
FACT supposes.

I think another solution for this issue is to leave the remained (actually only 
a little) disagreement for further discussion, so that at that time we may have 
more time to deal with it and based on more understanding of the problem we may 
reach an agreement.

I'd like to hear Jamal and others' idea on this very much.

Best Regards,
Weiming

> case, then why are we spending so many cycles debating this issue ?

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