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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 21 Mar 2004 10:31:17 -0800

That's fine Jamal. I will add this note below.
BTW, do you disagree with any of the text below ?

Lets discuss Security, Availability when we get to those issues.

Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Friday, March 19, 2004 6:06 PM
To: Khosravi, Hormuzd M
Cc: [email-masked]
Subject: Re: [Forces-protocol] Summary for issues 0-5

Hi Hormuzd,

I think issues 2-5 can mow be described with the TML separation.
i.e the TML layer will take care of:
- management of Multiple channels/connections
- Transport: unicast/multicast/broadcast
- Congestion control
- Reliability

We may as well add: security, availability.

Thoughts?

cheers,
jamal

On Fri, 2004-03-19 at 19:41, Khosravi, Hormuzd M wrote:
> 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
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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
> 
> _______________________________________________
> 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: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 21 Mar 2004 10:53:36 -0800

Weiming, Thanks for your comments !
See my replies below, I'll make the appropriate changes.

Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked].

[Weiming] I think we have also reached agreement on using LFB ID and LFB

Instance ID for addressing. Do you agree? 

[HK]Yes I will add this as part of the payload, good catch.

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)

[Weiming] We'v agreed to use priority bit(s), how it is defined
(1bit/3bits, 
and the semantics) need to be discussed further).
[HK] OK, I'll make this change,

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]

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)

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? 
[HK] I don't think so, let me know if you think I should add some text
that we have agreed on ?

---

From: "Putzolu, David" <[email-masked]>
Date: Mon, 22 Mar 2004 09:29:44 -0800

Hi Hormuzd - my feedback inline... 

On Monday March 22, 2004 9:09 AM Hormuzd wrote >
> Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length
> of Flags and Priority fields is TBD)

I'm not sure that this level of detail is good - was there
this much consensus?  Maybe instead say there was a consensus
on the inclusion of certain types of fields, but leave it for
later to get the exact # of bits etc.

On Monday March 22, 2004 9:09 AM Hormuzd wrote >
> Furthermore, in case of IP this will be a TCP or SCTP 
> connection between the CE and FEs. 

Careful - I only suggested use of TCP as an example.  It would
be up to the IP TML team to choose one of these (or DCCP, or
RMT).  

On Monday March 22, 2004 9:09 AM Hormuzd wrote >
> In addition to this, in case of 'close proximity'
> semantics of these Multicast connections is negotiated during the
> pre-association (TBD). 

I had a different impression.  Here is some alternate text 
for the team to consider on the unicast/multicast/etc issue:

The ForCES team reached consensus that ForCES would define a
set of transport requirements that must be met by any transport
implementation.  These requirements include an assumption of
support for prioritized connections, a reliable, ordered
unicast delivery service, and a multicast delivery service
(details TBD).

The ForCES team reached consensus that a set of concrete
transport mappings would be defined in order to achieve
interoperability on different transports.  An IP TML will
be defined that adheres to charter guidelines in regards to
use of a RFC2914-compliant transport, per AD feedback.  
Other non-IP TMLs will be defined as well.

The rest looked ok to me.

-David

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 22 Mar 2004 10:10:27 -0800

Thanks for the feedback, David!
See my replies below...

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Putzolu, David

I'm not sure that this level of detail is good - was there
this much consensus?  
[HK] Yes I believe we had clear consensus on these fields.
I have put a TBD for whatever there was no clear consensus on.

Careful - I only suggested use of TCP as an example.  It would
be up to the IP TML team to choose one of these (or DCCP, or
RMT).  
[HK] This was in context with the reliable unicast connection, thus 
I mentioned TCP or SCTP as per Jamal's comment.

[HK] I can add this text as well. However, I did incorporate 
any comments I received from Jamal, Weiming on the previous para.
Also, I think it captures some of the details we discussed. 
What do others think ? I am fine with either/both the texts.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 22 Mar 2004 12:37:28 -0800

Alright Jamal, I am fine with your comments and will 
make the changes that you have suggested below.

Thanks !
Hormuzd
-----Original Message-----

> > Another issue we reached agreement on was using LFB Type ID, LFB
> > Instance ID in combination of FE ID for addressing LFBs on the FE.
The
> > LFB IDs will be part of the payload.
> 
> Did you mean LFB instance ID?
> [HK] I meant both LFB Type ID and LFB instance ID mentioned in the
> previous sentence.
> I will clarify this explicitly in the text.

The LFBID is not something we agreed on as to be on the payload or the
header. The reasoning was that based on some threshold it may make sense
to put it in the header. At least i raised this in some emails.
so It is to be discussed as to where it belongs.
The Instance id is definetely in the body.

> In issue 0 you talk about LFB typeID. This is the same thing, no?
> [HK] I am not sure, this is something that you had mentioned but we
did
> not reach any agreement around whether it is needed or not, what are
the
> semantics, etc. That's why I have left it as TBD, I assume will be
> revisiting this in the future.

It is definetly the same one. So have both as TBD.

> Issues 2-5: I think that TML should be introduced first then you
should
> talk about TML satisfying those issues.
> Infact i feel there is no point in mentioning any protocols by name
> since its the TML thats responsible for delivering 2-5. Granted it may
> want to use TCP - but thats just an example.
> 
> [HK] Alright I will introduce some text on TML before describing these
> issues(2-5). BTW, I have not mentioned only TCP at any place, I have
put
> both TCP/SCTP as you, others had suggested.

I would think the generic view should be that of the TML.
Infact i started writting the HA text with explicit mention of the role
of the TML. I think this is the way we should proceed from now on.

---

From: "Putzolu, David" <[email-masked]>
Date: Mon, 22 Mar 2004 09:11:35 -0800

Hi all - my reply inline...

On Sunday march 21 2004 12:25pm Jamal wrote >
> 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).

I agree that most of the key players are already on this list.
However, the ADs are always very concerned about open-ness,
visibility, etc.  So it behooves us to at least come up with
a summary of any agreements/consensus areas.  A full justification
or reasoning for every single decision isn't needed, but there should
be enough so that a list reader could go over it and understand where
the protocol is going.

-David

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 22 Mar 2004 11:02:54 -0800

Incorporating David's feedback...

The protocol team reached consensus that ForCES would define a

The protocol team reached consensus that a set of concrete

The link below provides a good explanation of these layers...
http://www.sstanamera.com/~forces/proto/ForCESLayered.htm

There was some consensus around this text to describe the details...

congestion aware Multicast connections. (The establishment and semantics
pre-association - TBD). For example, the CE and subset of FEs might

Rest of the issues text is same as before.

Thanks
Hormuzd