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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 21 Mar 2004 11:00:45 -0800

Jamal, Weiming

If we all agree that the merger is possible then why cant we provide
some details to the WG about the discussions that we have had so far ? I
think its very important and we are obliged to keep all the members
informed about whats going on. This is part of the IETF open door
policy, everyone is entitled to know whats been going on. Unless we
don't agree with the summary sent out (which is not the case) I think
this is very important.

The other advantage to this is to have the WG members comment on any
issues that we don't agree on. Avri pointed this out and I think it
would be a very good way of resolving issues. Also, based on my
experiences on the Requirements RFC, I would prefer to have an open
discussion on the list upfront rather than repeat all the same arguments
later.

Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Saturday, March 20, 2004 3:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Forces-protocol] Summary for issues 0-5

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
> 
> 
> 
> 
> -------------------------------------------------
> This mail sent through HUCNIC Webmail system.
> 
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol

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

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 21 Mar 2004 15:25:04 -0500

> don't agree with the summary sent out (which is not the case) I think

I just checked who is subscribed to this list and now more than before
i am thinking we should focus our energies on getting over the rest of
the issues. 
Other than Joel and probably Lily, there is noone else who is not
on this list that contributes regularly (more than once a year that is).
If we had reached a good conclusion i would say, yes we should.
I think the WG is obligated to know at least we are heading towards
a merger. Thats the most important piece of information that needs to 
be delivered.
As you can see we already have small glitches with Weiming and myself
making comments. I really dont wanna be spending time correcting
little issues.  Lets finish the rest of topics - then we can post.
I will post the next two topics if noone else does.

> would be a very good way of resolving issues. 

Who are you hoping other than the people on this list already will
contribute - most of whom are merely lurking?
Joel probably should have been on this list. I am a little suprised he
is not. There is no big secret on what we are discussing here.
This is more open than anything else that any design team in Forces has
ever done (it is being archived).

cheers,
jamal

---

From: [email-masked]
Date: Mon, 22 Mar 2004 07:27:20 +0900

In this case, especially with the 20th having come and gone, it might 
be good for the the WG chairs to actually let us know what they expect 
to be delivered to the group.

I think the statement of possible merger, at the least, is due.  Even 
if we do still send the issue list, which I still think is reasonable, 
it does not need to go out at the same time.  And while I agree that 
spending a lot of time wordcrafting that list at moment seems time 
consuming when we should be covering the rest of the issues, it is also 
useful to know where the agreements really are (or aren't), so I do 
support Hormuzd's attempt to write this.

a.