Subject: [Forces-protocol] views on different channels vs same channel

From: Jamal Hadi Salim <[email-masked]>
Date: 02 Mar 2004 07:24:28 -0500

Hi,
since i have just scanned through tons of emails (halfway there),
let me share my view on the the topic. 

1) If you are using the same physical link at the lowest layer it doesnt
matter how many sockets/channels you have. The DoS impact is going
to be at the lowest layer i.e the physical link for which the only cure
is to have separate links. The next level up is just before the packet
is DMAed into RAM that the OS can get to it; there is some smart
hardware you can program to have multiple channels and drop at the 
earliest level. Majority of the hardware you will find cant do this.
Once the packet hits the OS, you can play with differentiation/QoS/rate
metering of either the CPU time and/or bandwidth protection.
Summary: having more than one virtual channel within one physical link
is going to offer little protection against DOS. 

2)On the sending: the value is going to be in having multiple queues
just before the packet hits the OS.
For this you need to recognize something in the packet. This does
not imply the ForCES header needs some speacial signature; rather the
packet can be administratively recognized and classified into a queue.
Example could be recognizing a destination IP or MAC address.

3)
The idea of having such unique names to "channels" is almost bell-head
approach. Reminds me of my ISDN days. There doesnt have to be a clear
cut explicit use for each channel (i.e thou shalt only transport data
packets). I am in agreement of having more than one connection, but the
approach is different.
Like i shared earlier on our experiences: the way we had the two or more
"channels" was to have different granularities of reliability.
We typically sent on a cheaper but less reliable mass transport and on
failure if the message needs to be reliably delivered then it goes
retransmitted on a more reliable unicast channel.

cheers,
jamal

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

---

From: jeff pickering <[email-masked]>
Date: Tue, 02 Mar 2004 08:31:14 -0500

Jamal,

I pretty much agree with 1), but would like to be careful about the term 
physical link.
In your example, if you have multiple DMA channels "listening" on a 
single physical
backbone, you can provide reasonable DOS protection. So maybe think of a 
logical
link as one where there is no overlap of underlying physical resource. 
The example
above would be a reasonable approximation if the backbone is much faster 
than the
DMA AND there was backpressure preventing backbone usage if one 
channel's DMA
is not available.

Jeff

---

From: Jamal Hadi Salim <[email-masked]>
Date: 02 Mar 2004 21:59:26 -0500

Jeff,

Agreed. I wasnt sure how commodity that feature was thats why
i refered to it as some smart hardware.
Our control hardware has two DMA channels on both tx
and rx; typically we reserve the higher priority channel for
control protocols and have strict priority scheduling
(leading to possibly the best effort DMA channel to be starved).
We can typically protect against most script kiddie type
DOS attacks with this scheme. 

cheers,
jamal

On Tue, 2004-03-02 at 08:31, jeff pickering wrote:
> single physical backbone, you can provide reasonable DOS protection. 
> So maybe think of a logical link as one where there is no overlap of 
> underlying physical resource. 
> The example above would be a reasonable approximation if the backbone is 
> much faster than the DMA AND there was backpressure preventing backbone 
> usage if one channel's DMA is not available.

[..]