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

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

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>  

      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? 
   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>
         End of comment 
        Regards
        Ramg

---

From: "Sandy Pavel" <[email-masked]>
Date: Fri, 27 Feb 2004 11:07:04 -0500

See comments below:
 
 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?
 
[[Sandy]] 
I am concerned about the separation of the D and C packets at the ForCES
protocol layer. I wonder if it is not too late at both ends of the
communication channel; by this I mean resources are allocated to
distinguish between the two but DoS might have already occurred or C
packets might have already been lost due to congestion on D. I believe
marking the two types and doing the separation at transport layer is
safer and uses existing mechanisms that do not overload the protocol.
Differentiated scheduling for D and C would be my preference. And yes,
there should be a differentiation between C and D for transport
reliability.   
[[Sandy]]

---

From: "Weiming Wang" <[email-masked]>
Date: Sat, 28 Feb 2004 11:41:56 +0800

Hi Sandy,

Thank you for the comments. Pls see reply in the lines.

----- Original Message ----- 

  From: Sandy Pavel 
  To: [email-masked] 
  Sent: Saturday, February 28, 2004 12:07 AM
  Subject: RE: [Forces-protocol] Fw: ForCES Protocol Analysis Design Team Administrivia

  See comments below:

           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?

          [[Sandy]] 

          I am concerned about the separation of the D and C packets at the ForCES protocol layer. I wonder if it is not too late at both ends of the communication channel; by this I mean resources are allocated to distinguish between the two but DoS might have already occurred or C packets might have already been lost due to congestion on D. 

          [WangRe]

          I can not find any reason it will be delayed more to schedule D and C packets at ForCES protocol layer than to schedule them at the transport layer. Actually the former happens ahead of the latter.  

          I believe marking the two types and doing the separation at transport layer is safer and uses existing mechanisms that do not overload the protocol.  

          [WangRe]

          Could you give more reasons why it is safer to schedue the D/C packets at the transport layer? My opinion is they are the same, except one is done by OS kernel scheduling (usually using round robin), the other is done by ForCES assigned scheduling whose scheduling

          decispline can be flexibly set by ForCES protocol, and D/C packets can be very easily and differentialtedly scheduled. 

          Differentiated scheduling for D and C would be my preference. 

          [WangRe]

           By saying to use united scheduling, I actually mean it may be able to exploit more from usual separate scheduling. If it is impossible (we are doing experiments to try it), there is no any limit for us to separately schedule D/C packets as usual. 

          And yes, there should be a differentiation between C and D for transport reliability.   

          [[Sandy]] 

          [WangRe]

          Actually I agree to differentiate the D/C packets for its transport relaibility, if possible. Maybe I should have stated the question as " Is it worthy or not to define a separate transport layer channel for D packets in ForCES protocol specifications  to only achieve a little lower reliability for the D packets transmision?"  Taking the chance to reply your comments, pls allow me to point out more cons on this: 

          1.  First of all, as I'v mentioned, such a D channel is only of use for assigning different transport reliability for D packets. It has no use for DoS protection. 

          2. Such a little difference for reliability requiements can be distinguished via ForCES protocol built in mechanisims by deciding to or not to use something like ACK, checksum, etc.

          3. To define a separate channel for D packets is also very case specific. That is, in UDP/TCP based CE-FE interconnection case, we may think of using UDP for D packets and TCP for C packets. But what then if the  CE-FE link is Ethernet based, ATM based, backplane bus based, and any future technology based?  Are we going to define it one by one? And what then if the CE-FE link can only provide a channel? 

          4. On countrary, it surely consumes more resources and makes ForCES protocol management more complex. 

          Best regards,

          Weiming