Subject: Re: [Forces-protocol] Summary for issues 0-5

From: [email-masked]
Date: Sun, 21 Mar 2004 01:20:54 EST

Hi All,

Definitely the merger is possible. Lots of details remain to be worked out. 
For example, I
still don't think the header structure has been fleshed out.  But the details 
can be resolved
later.

Regards,
Alex.

In a message dated 3/20/2004 5:21:26 PM Central Standard Time, [email-masked] 
writes:
Can we just say to the WG that there is consensus for a merger 
without providing details?
Looking at this and previous email from Weiming as well as my previous
concerns in the last email i posted, i think we dont loose anything by
not providing details. Instead lets reserve the energy for coming up
with the protocol and other related details.

cheers,
jamal

On Sat, 2004-03-20 at 01:46, [email-masked] wrote:
> Hi Hormuzd,
> 
> Thank you for your work on the summary.
> Please see some replies inline.
> 
> Weiming
> 
> ----- Original Message ----- 
> From: "Khosravi, Hormuzd M" <[email-masked]>
> 
> Hi All
> 
> Here is a brief summary of all the major issues that the team discussed.
> 
> Issue# 0 IDs in the header:-
> There was a lot of discussion on this topic regarding the naming,
> semantics, length of these IDs.
> The result was as follows...
> Naming: CE ID, FE ID
> Semantics: Used to address a single, group or all CEs/FEs respectively
> Length: 16-32 bits...TBD
> 
> [Weiming] I think we have also reached agreement on using LFB ID and LFB 
> Instance ID for addressing. Do you agree?
> 
> Issue# 1 Header/Encoding:-
> Here are the fields in the common header that there was consensus around
> IDs: as summarized in issue 0
> Version/sub-ver: 4 bits
> Sequence No. : 32 bits
> Length : 16 bits
> Command Type : 8 bits (semantics - TBD)
> Flags: 16 bits, including 3 bits for Priority. (The semantics/length of
> this is TBD)
> 
> TypeID: TBD, no consensus on whether it is needed or not
> 
> [Weiming] We'v agreed to use priority bit(s), how it is defined 
(1bit/3bits, 
> and the semantics) need to be discussed further).
> 
> Issue# 2 Multiple channels/connections:-
> There was a lot of discussion on this topic as well. There was agreement
> on the fact that there MUST be a way to prioritize and separate Control
> and Data traffic. There was no clear consensus around mandating using
> separate channels or connections (better term) for Data and Control in
> order to provide this separation. There were reasons presented regarding
> the ineffectiveness of separate connections to help during DoS attacks
> as well as the reasons for using reliable and unreliable connections for
> Control and Data respectively. The use of separate
> transports/connections is TBD.
> 
> [Agreed]
> 
> Issue# 3 Transport: unicast/multicast/broadcast:-
> There was some consensus around this text to describe this issue...
> 
> All ForCES protocol implementations, MUST support a reliable, congestion
> aware Unicast method of communication between the CEs and the FEs.
> Furthermore, in case of IP this will be a TCP or SCTP connection between
> the CE and FEs. In addition to this, in case of 'close proximity'
> between the CEs and FEs And in case the interconnect between them
> supports multicast, the CEs and FEs Must also establish reliable,
> congestion aware Multicast connections. The establishment and semantics
> of these Multicast connections is negotiated during the
> binding/capability discovery phase in the ForCES protocol or during
> pre-association (TBD). For example, the CE and subset of FEs might
> negotiate on establishing a Multicast connection for communication of
> IPv4 LFB attributes. These reliable, congestion aware connections will
> be used to communicate the control messages outlined in RFC 3654
> (section 6, #6c). (For data messages such as those outlined in RFC 3654
> (section 6, #6b), the ForCES protocol Must/Should also support an
> un-reliable but congestion aware Unicast connection between the CE and
> FEs.- TBD:issue# 2)
> 
> David provided some clarification to the group on this issue via his
> email below...
> https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren
> t/msg00317.html
> There seems to be consensus around the approaches outlined by David in
> his email.
> 
> There was also general consensus about separation of the ForCES PL
> (protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The
> link below provides a good explanation of these layers...
> http://www.sstanamera.com/~forces/proto/ForCESLayered.htm
> 
> Issue# 4 Congestion control:-
> General consensus was that Congestion Control (CC) is a MUST for the
> protocol for all messages, whether Control or Data in order to meet the
> basic scalability requirement. There was also some discussion around DoS
> protection in context with CC, but this is still being discussed.
> 
> [Weiming ] Haven't we achieved anything on DoS? 
> 
> Issue# 5 Reliability:-
> General consensus was that Reliability is a MUST for all control
> messages. The separation of TML from PL has provided the team the
> opportunity to make progress on the PL and defer the details of the TML
> for now. This issue is also closely related to issue# 3 and both were
> discussed in parallel to some extent.
> 
> In general, I believe we made a lot of good progress :-)
> Let me know if you guys have any comments on this summary ?
> 
> Thanks to everyone for their contributions!
> Hormuzd

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 21 Mar 2004 17:39:50 +0800

Hi Alex,

I agree with you. What I'v just posted also means this. Now we only need to decide is if the merger is possible, we then can have lots of time discussing the details, including the summary for previous discussions. 

BR
weiming
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] 
  Cc: [email-masked] 
  Sent: Sunday, March 21, 2004 2:20 PM
  Subject: Re: [Forces-protocol] Summary for issues 0-5

  Hi All,

  Definitely the merger is possible. Lots of details remain to be worked out. For example, I
  still don't think the header structure has been fleshed out.  But the details can be resolved
  later.

  Regards,
  Alex.

  In a message dated 3/20/2004 5:21:26 PM Central Standard Time, [email-masked] writes:

    cheers,
    jamal

    On Sat, 2004-03-20 at 01:46, [email-masked] wrote:
    > [Weiming] We'v agreed to use priority bit(s), how it is defined (1bit/3bits,