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

From: "Putzolu, David" <[email-masked]>
Date: Fri, 12 Mar 2004 09:49:57 -0800

Here is my understanding of the reasons for
separate channels for different priority traffic
(for now I'll leave aside whether C & D are the
different priorities or if there is some other priority):

1) If I build hardware that has two physical channels, but
   ForCES carries everything in a single logical connection,
   it becomes impossible (short of extremely ugly layer
   violations) to use my dual channel hardware, because all
   the ForCES messages are coming down in a single stream.

2) If I build hardware that has one physical connection, but
   has multiple levels of QoS (e.g. Ethernet backplane with
   support for 802.1p), but ForCES carries everything in a
   single logical connection, it becomes impossible to utilize
   my hardware's QoS support (short of those ugly layer 
   violations - Ethernet MAC chip cracking the ForCES header 
   to look at priority bits)

3) If I build hardware that has one physical connection, and
   no support for QoS,  but I design ForCES to carry things in
   separate logical channels, I can easily map them down to
   the single physical channel. This is merely a problem of
   multiplexing, and is normal for lower layers to do.

Basically, if one puts everything on one logical channel, it
precludes some very realistic, beneficial, and deployed 
hardware approaches.

If one puts different priority traffic in different logical
channels, one enables those hardware approaches without
precluding anything.

I'll leave the question of C & D for another email, got a
meeting to run to :)

-David

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Mar 2004 18:16:22 -0500

Hi David,

Let me do a compare with a node with two ethernet ports
to put into context what you are saying. I suppose we can assume 
we can attach IP addresses to these ports. If we are going to run 
over IP, then such a node is refered to as multihomed.
Is this a fair corelation?

Lets refer to sockets as the logical connections.

>    the ForCES messages are coming down in a single stream.

So you have one socket but two ethernet ports.
If i understood you corectly, lets say you had 10 ethernet ports, would
you then say you want to take advantage of all of them? 
I suppose you have to draw a line somewhere which seems to me this is a
config choice, no?
If you are running on top of SCTP it would manage this for you.
BTW, didnt get the layer violations you are refering to.
An alternative is to use simple lower layers tecniques like
trunking/bonding. 
I dont think you require to manage the knowledge at the Forces level.

>    to look at priority bits)

So one ethernet, one socket. 
I know in Linux it would be trivial to map the Forces prio bits to
either diffserv or 802.1p on the sending side. 
The Forces prio bits are more valuable IMO at the application level
where you can process higher priority before lower priority etc.
This May be orthogonal to whatever prioritization bits at the lower
levels.

>    multiplexing, and is normal for lower layers to do.

sure.

> precludes some very realistic, beneficial, and deployed 

I dont think multiple hardware paths should be precluded.
What we need to understand is the nature of the beast.
What differentiates the different "channels" and when to use them.
I suppose the other question is "how many channels" - or is this a
config issue? I dont see anything nmagical about the number 2.
Or D & C.

> channels, one enables those hardware approaches without

Nothing stops that as far as i can see.

> I'll leave the question of C & D for another email, got a

Waiting ;-> I really am having ISDN dejavus, but wuill wait to hear the
reasoning first.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 14 Mar 2004 23:21:29 +0800

Hi David,

Firstly, I really appreciate you have presented a very helpful scenario for the
discussion.

Please see reply inline.

----- Original Message -----
From: "Putzolu, David" <[email-masked]>

[Weiming Re: Actually you have raised another question, that is how ForCES can
couple with the case where there are multiple  hardware links (2, 3, and even
more) between a CE and a FE.
It's true that the C/D channel separation in physical link may fit well to 2
physical links case, but how about 3, 4 or more physical links? I noticed that
Jamal has also noticed this. Because we can not force the implementation layer
to use how many physical links (2,3,4...), I have to say not to explicilitly ask
for C/D channel separation in ForCES protocol is still more reasonable. That
means if they have exactly two links, they may use C/D separation, if they have
more, they may not use such separation.
There is another question how one stream can be coupled with two or more
physical links. Actually there are many techiniques toward this such as
demultiplexing . But I would prefer not to mention this in the protocol, to
leave it to the implementation layer.
]

[Weiming Re:
This is exactly what GRMP has already paid attention. Please allow me to quote a
part from GRMP  to better explain it.

Quote GRMP P. 47:
 DoS Protection Policy has the data format as:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| CCP |        Reserved       | BW Lower Limit| BW Upper Limit|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D| DCP |        Reserved       | BW Lower Limit| BW Upper Limit|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C, D Tag:
   Control channel, Data channel priority
         0 - Normal priority
         1 - High Priority
   Note that the function of the priority here is different from that
   of the priority flag in GRMP message headers. This priority is only
   for the message transmission priority between CE and FE, while the
   priority in message header is for CE or FE to process the message
   when it arrives at CE or FE. Priority in GRMP message header has no
   effect on protecting DoS attacks for attackers are also able to set
   the priorities.
/quote

From above description,  we know that the priority for DoS protection is defined
as an FE attribute instead as that in the message header. The priority for DoS
protection (as well as for congestion, reliability) is different from that
defined in ForCES header, which is just for message processing when the messages
has already arrived at terminal. In this scheme, there is no difficulty (no ugly
layer violation) for the priority to be mapped into transport layer. (Note that
when GRMP mentioned Control channel and Data channel avove, it does not mean a
channel in the physical link. Actually I suppose in the multilevel Ethernet QoS
case, the channel idea also only exists at the sender and receiver side
(different queues) instead in the physical link.
]

[Weiming Re: This is why I propose we should use "RECOMMEND" instead "MUST".
Just as you mentioned here, some may not support different channels. If we use
"MUST", they may think that they can not meet the requirements and just abandon
using ForCES.
]

[Weiming Re: by using the idea like the DoS protection policy as an FE attribute
(Of course the policy contents in GRMP still need to be polished), the transport
layer benefits can be adpoted. On the other hand, I still don't see multiple
channels/connections in the physical link help more for this.
]

Sincerely,
Weiming