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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 18 Mar 2004 23:54:30 -0800

Jamal,

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> #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.

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.
[HK] We do need an asynchronous notification message to report some
event like this. However, it should be triggered by the FE and not the
protocol. Do you agree ?

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

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.
[HK] What about in order delivery ? I think this is also covered by this
point but just wanted to confirm.

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. 
[HK] Agreed, here is where a protocol level response or ack is useful.

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

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.
[HK] The only other thing needed is protocol level Response or ACK. Is
this what you mean ?

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

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.

[HK] Agreed, I like the idea of Transport Abstraction as well.

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

---

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

Hi Hormuzd,

> From: Jamal Hadi Salim [mailto:[email-masked]] 

[..]
> event like this. However, it should be triggered by the FE and not the

I am begginging to worry that this is going to get very complex 
in order to reach a middle ground;-<

I think we need a class of messages under the banner of "Forces Control"
messages within the protocol where this will fit in; this is in the same
vein as ICMP is the IP control protocol.
I dont think we need an extra protocol such as ICMP. Message should be
able to come from either FE or CE. Coming from the FE should be to tell
the CE whats going on and have it make a call. Coming from an CE i would
think is for a policy installation to mitigate a congestion problem at 
either CE or FE.
There is an ICMP message (currently deprecated) called Source Quench
which is sent when an IP node is overwhelmed such as when its queues are
getting overloaded. We could adopt something along the same lines.
We just need to have more than one reason for why a node is getting
overwhelmed and maybe when possible have the message define a course of
action. Note again, I am trying to reach a middle ground so we can move
on.

> point but just wanted to confirm.

Good catch: Ordering is typically not defined in reliability.

You could have reliable protocols which deliver unordered messages eg
SCTP provides such an option.
Note however:
Since we are looking at this at the Forces level, the message becomes a
complete Force message then ordering is implied.
This is actually the reason i posed the question to David on his diagram
on whether the TML->PL is serialized in terms of message delivery.

We could have ordering as a separate topic or we could assume the above.

> [HK] Agreed, here is where a protocol level response or ack is useful.

Yes, the sender needs to be provided with assurances that the message
made it, and that it made it fine within a valid time.
So Forces level ACKs, checksum and timeout would be the right things to
have.

> [HK] The only other thing needed is protocol level Response or ACK. Is

and checksums; i think timeouts may need to explicitly be called in the
text but we could leave that to the TML.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 19 Mar 2004 07:36:08 -0500

> > > #5- Reliability:

A friend of mine sent me a very good URL which talks about this topic in
a slightly different context.

http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0164.html

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 19 Mar 2004 21:27:23 +0800

Hi Jamal, Hormuzd,

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>

Jamal,
-----Original Message-----
>
> #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
> 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

I think i have an idea on how to resolve Weimings thoughts on DOS protection:

[Weiming] Absolutely.

[Weiming]  Yes, a rate limiting like LFB should be used to detect as well as to
limit the D packet stream.  But two reasons that make me believe we should have
it defined in the protocol scope: 1) To decide if there is a congestion or a DoS
on D packet stream is also highly related to C packet stream status. That is,
even if someone is actually making an attack, but before it has threatened the C
packet stream with a danger of congestion, it may not be considered a DoS
attack, and we'd better not to start the rate limiting for D packet stream. This
means a DoS or congestion event report is better to be generated by detecting
the status of C stream instead of D stream. 2) DoS and Congestion control should
be considered as a MUST item. If we leave it defined by use of LFB, we actually
make it a kind of optional and vendor-specific item. This has also made the
interoperability regarding the DoS and congestion mechanism very bad.

But anyway,  to see the neccessary of such a congestion notification ( alert) is
the main purpose for our discussion. We may leave how to implement it to later
discussion.

> reliability' as defined in the Requirements ? I assume the answer is yes

> built into the protocol or reused from existing transports ? There are a
> protocol simple and don't spend our energies in re-inventing the wheel.

> will be useful to have a separate section/draft which will address these

[Weiming] Me too.