Subject: RE: [Forces-protocol] Issue 4&5: Congestion control, DoS protection, and Reliability

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 18 Mar 2004 13:39:34 -0800

Weiming,

Thanks for getting these issues started.
Here are my thoughts...

#4- Congestion Control:
Congestion control is important for the ForCES protocol in order to meet
the Scalability requirements. As we start going from 10s of FEs to 100s
and even thousands of FEs, we will need to have congestion control
mechanisms in the protocol. There was a general agreement on this topic
on the ForCES mailing list, when we had the discussion around multicast.
I think we should separate the discussion around Congestion Control from
the DoS protection discussion.

So to address your email, the answer to #4,5 below is 'Yes, CC is
important for both control and data messages'. Also, I am fine with #3
below but we should discuss the specifics of that issue later. Is that
fine ? What do others think about this ?

#5- Reliability:
Couple of questions need to be answered here...
What exactly does everyone mean by Reliability ? Do they mean 'strict
reliability' as defined in the Requirements ? I assume the answer is yes
to this one, but just want to clarify it.

The second question is whether the Reliability/CC mechanisms should be
built into the protocol or reused from existing transports ? There are a
couple of cases here and the answer would depend on the case...
1. ForCES over IP: We can easily reuse existing Transports such as
TCP/SCTP over IP to provide reliability, CC, etc. This way we keep the
protocol simple and don't spend our energies in re-inventing the wheel.
2. ForCES over L2: Here we could either build reliability mechanisms
into the protocol in an optional TLV/encapsulation header or use
protocols such as TIPC to provide this functionality. In any case, it
will be useful to have a separate section/draft which will address these
mappings (similar to GSMP/GRMP, etc)

So in context with your email below, I partially agree with what you are
suggesting but providing ways to break up and conquer this issue.

Let me know what you guys think ?

Regards
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]

Hi all,

To speed up, pls allow me to activate these issues. Actually we have had
quite 
a lot discussions related to these topics. I just try to first list some
items. 
Pls add some more.

* For DoS Protection and Congestion control

1. The idea to distinguish packets by Data packets and Control packets
should 
be used to protect against DoS and control congestion, where Data
packets are 
actually redirected packets by FE to CE.

2. To further protect DoS and control congestion, something like a FE
DoS 
Protection & Congestion Control Policy should be included in ForCES
protocol. 
The policy may include that like priorities and rate limiting parameters
for 
both C and D packet streams, and may be mapped to ForCES protocol layer 
scheduler or OS layer scheduler (need more discussion on which is
better). For 
D packet stream, because it is a dataflow in FE model before being
encapsulated 
as a ForCES message, it is possible an LFB be adpoted to do such rate
limiting. 
For C packet stream, it is surely done out of the FE model scope. 

3. A DoS (or Congestion) alert mechanism is necessary for ForCES
protocol. 

4. Even without DoS, congestion can also happen, for sometimes there may
be too 
many C packets that need to be transmitted. 

5. Do we need to consider congestion at the CE side? (Avri raised this
question 
to me). 

* For reliability

1. A built-in mechanism for reliability like ACK, Checksum, and
Dual-phase 
commit must be included in the protocol specification. 

2. Differentiation of reliability for different protocol messages may be

achieved at the transport layer and/or at the protocol (core) layer. 

I just stop here currently. Pls move forward quickly.

Regards,
Weiming

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

---

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

Hormuzd,

Skipped your other email since i am trying to catchup and this one
references Weimings.

> the DoS protection discussion.

I think that congestion control MUST be met. Perhaps we should look at
some of the ideas of DCCP for pluggable congestion algorithms.

I think i have an idea on how to resolve Weimings thoughts on DOS
protection:
If we look at DOS indicator as an explicit congestion notification,
then we could squeeze it under those auspicies.
Ability to provide intelligent explicit feedback for congestion control
would be useful in general. Of course  DOS being one item of a bigger
set of issues that create congestion. 
I am not sure i like the way GRMP is doing it, but i also think we
should be able to satisfy this desire under the auspicies of Explicit
Congestion notification.

> to this one, but just want to clarify it.

I am always thinking of the academic definition. Sorry, I had to
cutnpaste from an old posting i made.

1) Message is delivered with integrity. 
This means the mesage is delivered identical to what was sent.
Additionaly only _one_ copy is delivered.

2) A valid message is delivered. 
And in this portion a timeliness connotation comes in. 
The "valid" part infact defines a time limit where the message is
considered useful. 

> protocol simple and don't spend our energies in re-inventing the wheel.

Note that even when you use TCP or SCTP the reliability is to be defined
at the application/ForCES layer. Reusing above transports should help.

> mappings (similar to GSMP/GRMP, etc)

Lets not rush into separating them for now.

To be honest there is no one transport that can satisfy all the needs
thats why we need all those connections.
Hence the idea of a transport abstraction is sane. If we leave
say the responsibility of conegstion control, reliability, security,
avaliability to this abstraction layer we can make good progress.

cheers,
jamal