Subject: Re: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team Administrivia

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 27 Feb 2004 22:26:20 +0800

Hi Ram,

Because the file is too big, I just pick one of them. 

[<Ramg>]  As you pointed out exactly that BGP runs on TCP and provides its own reliability mechanism and so as other routing protocols have some form of inbuit mechanism and this is the reason
we need not address in our ForCES protocol for data channel. Some traffic we don't need retransmission and reliability in D channel as it is handled by those protocols themselves.  <RamG>
WangRe: as I have replied to Alex, I just suppose if we don't have to separate the D/C channels in the physical link (instead only separate it inside an FE), are we still interested in
appointing to D packets different transport reliabilities? 
 [<Ramg>] 
Yes.
<RamG>
WangRe: could you present more reasons apart from the D packets are not as important as C packets, to show the worthiness to use different 
channels and different reliabilities for D and C packets? 
Thank you.
Weiming

---

From: [email-masked]
Date: Fri, 27 Feb 2004 09:11:32 -0500

Hello Weiming,
comments are inline

-----Original Message-----
From: ext Wang,Weiming [mailto:[email-masked]]
Sent: Friday, February 27, 2004 8:59 AM
To: [email-masked]
Cc: Gopal Ram (Nokia-NRC/Boston)
Subject: Re: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team Administrivia

Hi Ram, 
 
Glad to see your comments and please find the reply inlines. 
 
Best regards,
Weiming

----- Original Message ----- 
From: [email-masked] 
To: [email-masked] ; [email-masked] 
Sent: Friday, February 27, 2004 9:35 PM
Subject: RE: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team Administrivia

Hello Weiming,
 
Alex missed out my name in his first email. See my comments inside  the tag <Ramg>  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Wang,Weiming
Sent: Friday, February 27, 2004 7:56 AM
To: [email-masked]
Subject: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team Administrivia

Hi Alex,
 
Thank you for your comments. Pls see the inline reply.
 
Best regards,
Weiming

----- Original Message ----- 
From: Alex  <mailto:[email-masked]> Audu 
To: Wang,Weiming <mailto:[email-masked]>  
Cc: avri <mailto:[email-masked]>  ; Chaoping Wu <mailto:[email-masked]>  ; Deleganes Ellen M <mailto:[email-masked]>  ; Dong, Ligang <mailto:[email-masked]>  ; Guo, Yunfei <mailto:[email-masked]>  ; Jamal Hadi Salim <mailto:[email-masked]>  ; Jeff Pickering <mailto:[email-masked]>  ; Jon  <mailto:[email-masked]> Maloy ; Khosravi, Hormuzd M <mailto:[email-masked]>  ; Patrick  <mailto:[email-masked]> Droz ; Putzolu David <mailto:[email-masked]>  ; Robert  <mailto:[email-masked]> Haas ; Spyros Denazis <mailto:[email-masked]>  ; Steve  <mailto:[email-masked]> Blake ; Wang, Guangming <mailto:[email-masked]>  
Sent: Friday, February 27, 2004 2:06 AM
Subject: Re: ForCES Protocol Analysis Design Team Administrivia

Hello Weiming,

I'll address some of the issues you raised.

1) Seperate Data Redirect and Control channels/ relative importance of Control vs Redirect info
    It is easy to see that the redirect data can be manipulated by an outside source (External to 
     the NE).  In the case of such a source being malicious, it is necessary to give priority to 
     the control data to maintain integrity of the NE.

      You sighted BGP experience.  Indeed, the realization that it is safer to separate externally
       generated control data like redirect-data from internally generated control data grew out
       of  experience gleamed from past DOS attacks on BGP.

2)  C channel and D channel are on the same physical link.   For DOS survivability, you need 
      to seperate then somehow. If you use SCTP, you can put them on separate streams on
       the same link. That will work.  But what will be best is a non-reliable congestion aware
      stream/link for  D-channel and a reliable stream/link for C-channel.
       Rate controlling is important. But if  you need to allow your C information to flow freely
       to adaptively effect counter-meassures if the NE is being DOS'd.

Re. 1&2:  I suppose a separation of D and C packets inside FE while using only one stream(channel) to accross the 
physical link (GRMP DoS protection scheme) can also achieve all these goals (DoS protection, rate control, priority, 
security, reliability). We just ask that if we don't need to provide the two diffenrent channels in the physical link so
 as to prevent DoS, are we still interested in giving the D packets a different transport reliability?

3) Delay of D packets by  delay of C packets.   This sould not happen if your channels are
     independent. And  D packets may dictate what C packets get sent to the FE.  The
     problem might be related to the way your real-time processes are running the D and C 
     queues.  You can play with thread priorities,..etc to resolve this.

Re: Yes, this is because of the congestion of queues of D packets and C packets, but the same will
also happen to separated D/C channels if they use the same physical link. Only the difference is the latter
may use OS kernel to schedule while the former uses ForCES protocol defined scheduler. 

4) C/D separation resource cost:   This is not as expensive as the cost paid when DOS
     attacks occur.  Besides, hardware resources are getting cheaper by the day,..and 
     processors are getting faster too.  
 
Re:  again, by separating the D packets and C packets inside an FE, we can also prevent DoS efficiently. 

General comments. May be a way to go forward is to make it a SHOULD to implement
 (on seperate D/C channels) and leave the rest up to implementation,...I am not sure. Any comments?
 
Re: I agree. What we propose is only to limit such a separation inside an FE instead of expanding it to the FE-CE link.

Regards,
Alex.21

Wang,Weiming wrote:

Hi David,

Regarding the proposed basic principles, we (GRMP group) have some comments for  principles item 7&8:

--------

7.      The ForCES protocol should support separate channels for Control and Data messages. The data 

channel carries the routing/control protocol packets such as RIP, OSPF packets, between the CEs and FEs. 

These packets are unique in most cases for a particular CE:FE pair and hence the data channel will use unicast 

connections between the CEs and FEs. Also, the data channel does not have to be strictly reliable but does 

need to provide flow/congestion control to protect against DoS attacks.

8.      The control channel must provide strict reliability (non-corruption, no loss, no reordering, timeliness) at the 

transport level in accordance with the RFC 3654. In addition, ForCES protocol level responses/acknowledgements 

are also needed from FE to CE to learn the results of configuration/control messages.

--------

First of all, we agree that to distinguish ForCES messages into control messages and data (redirect) messages are 

essential for DoS protection scheme. Then, we argue that to separate the two kinds of messages into two different 

transport channels with the data channel being appointed to a lower reliable level (such as UDP, compared with TCP) 

may not be a good enough scheme for such purpose. The reasons are:

1. The data (redirect) ForCES messages seem have no reason to be appointed to a lower reliability, compared with 

control channel messages.  We may needn't  to argue how important some of the redirected messages are for a 

router (an NE), we just argue that  the reliability for ForCES data message transport should not be lower than that of the 

connection over which the routing/control protocol packets  are transported. An example is the BGP protocol messages, 

which have already been assigned to use TCP instead of UDP for the transports. We think the communication between CEs 

and FEs (which is inside an NE) has no reason to greatly induce extra performance loss other than that from outside of 

an NE for such routing protocol packets. By saying this, we don't mean all ForCES messages should not be loaded over UDP, 

we just propose that it's may be too early to distinguish the redirect messages from other configuration messages inside ForCES 

protocol specifications.

[<Ramg>]  As you pointed out exactly that BGP runs on TCP and provides its own reliability mechanism and so as other routing protocols have some form of inbuit mechanism and this is the reason
we need not address in our ForCES protocol for data channel. Some traffic we don't need retransmission and reliability in D channel as it is handled by those protocols themselves.  
<RamG>
WangRe: as I have replied to Alex, I just suppose if we don't have to separate the D/C channels in the physical link (instead only separate it inside an FE), are we still interested in
appointing to D packets different transport reliabilities? 
 
[<Ramg>] 
Yes.
<RamG>
   2. Generally speaking, separated C channel and D channel are still put over the same physical link (or else there is almost 
no need to protect DoS). Therefore, such a separation itself does not provide any DoS protection, instead, the protection is obtained by the rate control of D channel. We argue that such a rate control actually can be obtained at the ForCES message layer instead of at the message transport layer. Some of our experiment results (which will be presented at the IETF meeting) have shown this feasibility. Moreover, a separation at transport layer surely will complicate the CE-FE association and the followed message transport management. 
[<Ramg>] 
 
I think everyone agrees this and understand this point. It is the CE which uses ForCES Message to convey the ratelimting value for C and D channel FE. It is the FE which forwards the packet to the CE and hence one FE need to know the parameter. Here the rate limiter values could be different in either direction..
 
WangRe: yes, I totally agree.
 
 3. We have also noticed a phenomenon during our experiments, which we may need to pay some attention. I recalled when FACT first presented the D and C channel idea, there was a question worrying about the asyncronization between D and C channel. Our experiments have shown that, although there is no strict asyncronization problem between D and C channel owing to the data independence, there is a possibility that D channel packets may be seriously delayed and even blocked owing to the busy traffic at C channel if D packets are separated from C packets. The busy traffic at C channel may happen when CE queries FE for something and FE dumps quite a huge number of messages (such as routing table items.) Such a delay or blocking may be counted in seconds, resulted in very harmful effect on the users of redirected packets. As a result, we propose that a moderate rate control for C channel be also necessary. 
[<Ramg>] 
 
Please see the previous reply. The dumping of huge data confirms to the rate limiter value which was done and acks are being presented in FACT layer to ensure that message delivery and message execution. We have implemented this and it is running fine.
 
<Ramg>
 
WangRe: we just want to point out this D pakcets blocking facts for more attention. I'm glad to know that FACT also use some rating mechanisim for C channels as well as D chennels, because GRMP also be in this way. 
 
 4. To explicitly separate D and C channel also consumes more resources, because a resources for D channel have to be reserved. Instead, by separating D and C packets at the ForCES protocol layer and uniting them again at the transport layer, we may able to make a scheduling discipline by which the D and C packets can share the link resources effectively. We are trying to construct such a scheduling scheme, and it seems quite practical to so.To summarize, we propose that the 7&8 basic principles only mention the separation of D and C packets for DoS protection currently, leaving some space for further discussions. The discussions may be like: 1. Should such a separation be put at the ForCES message layer or at the transport layer? Which is better?2. Whether united scheduling for D and C packets are necessary?3. Should D packets be distinguished from C packets for its transport reliability in ForCES protocol so as to assign a different transport means?Regarding the protocol merge proposal, we'd like to present some of our thinking in a few words:Firstly, as a new comer to IETF work, the GRMP group surely welcome such a merge proposal, sincerely hoping an all merits in one draft can be achieved for ForCES WG, and at the same time hoping to learn from other candidate authors, whom we have already been respecting to for their rich knowledge and excellent contributions to IETF and other fields. Secondly, we believe that the interaction among the candidate drafts are very helpful for the final ForCES protocol. Actually there already has been such interaction since the ForCES protocol evaluation process began, which has already made individual candidate drafts ever improved. Thirdly, to make the process successful, we believe that a nice atmosphere is very important. In such an atmosphere, everyone has a peaceable state of mind, precisely speaking, a mind ready to give up and accept, and individuals' work can be fully respected. Our past experience has made us believe that it is almost impossible to reach a compromise among group members where some think of their work much outstanding to others. Lastly, as Jamal has mentioned, some ground rules is important so as to eliminate conflicts whenever there are. Regarding the merge action way, we agree candidates to propose their "can't live without" first. Along with this, we also suggest candidates propose "what they think the contents in their drafts are useful for final protocol and hope able to be put in it". This useful contents are a little different from the "features of the drafts", because we suppose the contents proposed should be conservatively considered by presenters to be able to merge with other contents. Thank you.Beset Regards,Weiming Wang
[<Ramg>] 
If we make separation on transport layer then we have few transport choices and many not be widely deployable. It is upto the group to decide. If we deal with the ForCES messaging layer then it has this messaging can be applied to other non-ip transport too.
 
WangRe: yes, I totally agree. What we propose is exactly to limit the separation of  the C/D packets into ForCES C/D messages instead of expanding such a separation into transport layer (over physical link). I'm not sure if I'v missed your meaning or not? 
 
<RamG>
If this is the case then we are in same understanding. Alex has given an illustration - how one can do with SCTP.
<RamG>

<Ramg>
 End of comment 
Regards
Ramg