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

From: [email-masked]
Date: Mon, 1 Mar 2004 13:33:46 +0800

Hi Hormuzd,

Nice having seen you in Seoul. Pls check the reply in the body.

Thank you.

Weiming

>----- Original Message ----- 
>From: Khosravi, Hormuzd M 
>To: Wang,Weiming ; [email-masked] 
>Sent: Monday, March 01, 2004 12:02 PM
>Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team 
Administrivia
>
>
>Weiming,
>
>After going thru all the emails on this topic, seems like most protocol 
authors as well as non-authors except yourself agree that there should be 
separate transports for C & D channel. 
[WangRe]
This actually does not mean much. I think it is techniques instead of votes 
which can resolve the problem. 

>2 good reasons have been given for this: different reliability and robustness 
against DoS attacks. You agree with the first but not with the latter. 
[WangRe]
Yes, my idea is that to use separate channel can supply different reliability, 
but cannot supply any extra awards for DoS. 

>The problem with implementing scheduling at the protocol level and sending all 
the messages over a single TCP channel is that the app or protocol scheduling 
has little control over the TCP queues inside the OS. So scheduling at the 
protocol level will not help during a DoS attack once the TCP queue inside the 
OS if full.
[WangRe]
The reality from our experiments is definitely not what you said. Scheduling at 
protocol layer can prevent DoS very well. We'll show the test results tomorrow. 
Could you have some reason why "the app or protocol scheduling has little 
control over the TCP queues inside the OS". Remember that the packets at TCP 
queues are supplied by app layer. 

>This is the reason why most people on this list are suggesting using different 
transports or multiple channels for D and C channel. 
[WangRe]
I suppose half of the replies mainly pay attention to the reliability problem 
when they support the separation of C and D channel.

>We can discuss this further during the meeting if you like.
>
[WangRe]
Yes that's a good idea if you also like. 

>BTW, I have been receiving many duplicate emails from you, but am not seeing 
all the other emails. There might be some problems with this mailing list.
[WangRe]
I hope the mailing list will not limit the length of one email within 40k, for 
it's easy to overload when HTML format is used.

>Regards
>Hormuzd

-------------------------------------------------
This mail sent through HUCNIC Webmail system.

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

---

From: "Putzolu, David" <[email-masked]>
Date: Sun, 29 Feb 2004 21:49:45 -0800

> it's easy to overload when HTML format is used.

40k was the default, I suspect because the IETF doesn't
want their servers overloaded.   Several emails where in the
40-55k range, so I've gone ahead and upped it to 60k.  If
that is still too small I'll see about increasing it further.

Cheers,
David

---

From: "Deleganes, Ellen M" <[email-masked]>
Date: Sun, 29 Feb 2004 22:42:34 -0800

I suggest including just the sections that you are replying to, rather
than include the whole thread. It is getting difficult to follow some of
the discussions because of the length of the emails. 

Regards,
Ellen

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Putzolu, David
Sent: Sunday, February 29, 2004 9:50 PM
To: [email-masked]; [email-masked]
Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis Design Team
Administrivia

Cheers,
David

---

From: "Deleganes, Ellen M" <[email-masked]>
Date: Sun, 29 Feb 2004 23:12:16 -0800

Hormudz,

Separating the protocol into two separate drafts is a good idea. I
suspect the items that you suggest for the first draft are not as
contentious (basic protocol messages needed for control, configuration,
capability exchange, etc. as well as other transactioning semantics
(2-phase commit), etc.) and the team will be able to make faster
progress. 

By separating the encapsulation part into a 2nd draft seems reasonable.
The second draft should have concrete details about how the ForCES
protocol maps to the transport (or transports). Since this is a mapping
document, the transports should be named so you don't have to specify
the assumptions on the transport, they can be deduced from the mapping
description and understanding of the transport protocol.

Regards,

Ellen

---

From: "Putzolu, David" <[email-masked]>
Date: Sun, 29 Feb 2004 23:48:16 -0800

This is an interesting idea but I suggest first 
applying as a way to structure work of the design
team before deciding whether to apply it to draft 
structure itself.

I.e. have the design team focus on areas of common 
protocol messages, then have the design team focus on 
transports.

Note that only 19 days are left before the report-out 
is expected on whether a merge is possible or not.  
So we need to work fast! :)

-David

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Deleganes, Ellen M
	Sent: Monday, March 01, 2004 4:12 PM
	To: Khosravi, Hormuzd M
	Cc: [email-masked]
	Subject: RE: [Forces-protocol] Re: ForCES Protocol Analysis
Design Team Administrivia

	Hormudz,

	Separating the protocol into two separate drafts is a good idea.
I suspect the items that you suggest for the first draft are not as
contentious (basic protocol messages needed for control, configuration,
capability exchange, etc. as well as other transactioning semantics
(2-phase commit), etc.) and the team will be able to make faster
progress. 

	By separating the encapsulation part into a 2nd draft seems
reasonable. The second draft should have concrete details about how the
ForCES protocol maps to the transport (or transports). Since this is a
mapping document, the transports should be named so you don't have to
specify the assumptions on the transport, they can be deduced from the
mapping description and understanding of the transport protocol.

	Regards,

	Ellen

---

From: "Sandy Pavel" <[email-masked]>
Date: Tue, 2 Mar 2004 16:30:50 -0500

Hi Weiming1
 
Sorry for the delay in answering to your comments.
Partial reason for this delay is that I could not see
what is actually your argument against my opinion.
 
In any case I believe Hormouzd has already summarized
very well  our arguments.
 
Regards,
Sandy
 
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: February 28, 2004 12:48 AM
To: [email-masked]
Subject: [Forces-protocol] Re: ForCES Protocol Analysis Design Team
Administrivia

Hi Sandy,
 
Thank you for the comments. Pls see reply in the lines. 

----- Original Message ----- 
From: Sandy Pavel <mailto:[email-masked]>  
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

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 2 Mar 2004 16:40:07 -0800

Ok, I am fine with that. It was just a suggestion to make progress on
the common parts such as

Protocol messages, that we agree on.

  _____  

From: Alex Audu [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2004 10:08 AM
To: Khosravi, Hormuzd M
Cc: Wang,Weiming; [email-masked]
Subject: Re: [Forces-protocol] Re: ForCES Protocol Analysis Design Team
Administrivia

Hi Again,

I am not sure if I replied too soon to your e-mail,..but on further
reflection,  I can see
why you made the recommendation.  Again, my answer is the same: no
double drafts.
The ForCEs protocol is transport independent by requirements specs.  So,
a well defined
protocol should work transparently well with any  transport.  

You can have different sections for each of the transports considered
and add comments
about any special thing that needs to be done or any special behavior to
accommodate
that transport mode.

Regards,
Alex.

Khosravi, Hormuzd M wrote:

Hi All

I was thinking about the issue of transport(s) for the ForCES protocol
which is probably one of the most important and might be quite
contentious.

One way to resolve this and make some progress is to separate this from
the ForCES base protocol, let us consider having 2 drafts...one which 

defines the base protocol assuming a reliable transport and the second
which defines how the base protocol will work over different reliable as
well as 

unreliable transports e.g. TCP/IP, UDP/IP, TIPC, Ethernet, PCI, etc. The
base protocol can concentrate on the basic protocol messages needed for 

control, configuration, capability exchange, etc. as well as other
transactioning semantics (2-phase commit), etc. The 2nd draft, say on
'encapsulation

for the base protocol' can discuss the details of providing reliability
over unreliable transports using some encapsulation header or TLV, etc.
and how

the base protocol will work over different transports.

We will eventually need to mandate 1 or minimum set of transports for
the protocol, but that can be decided later. In the mean time we can
continue 

making progress on both drafts. How does that sound to you guys ?

Let us know.

Regards

Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: 02 Mar 2004 22:15:44 -0500

Hormuzd,

On Tue, 2004-03-02 at 19:54, Khosravi, Hormuzd M wrote:
> Hi Jamal, All
> 
> I briefly chatted with David, Patrick regarding our deliverables by
> March 20th and I got a feeling that they are looking for whether we can
> merge the protocols and what are the high level design features that we
> all agree on.
> I think most of us already agree that we can achieve a merge if we work
> towards it. I would suggest that we first try to get all the high level
> features list out and agree on it, then proceed to the details.
> 
> So in that spirit I would suggest to postpone getting into details such
> as length of bits in the header, what the format is, etc for now and
> quickly come up with a list of common ideas. Some of the items below
> that we all seem to agree on may be a good start.
> 

We could make the encoding discussion the last thing but it needs
to be discussed as we are discussing the mechanisms.

The main discussion points as i see it (to extend what David posted)
are:

1) Encoding
2) Multiple channels/connections
3) Transport: unicast/multicast/broadcast 
{ TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 
4) Congestion control
5) Reliability
6) Security
7) High availability

Its almost like 2-5 are very closely related.

I am doing this off the top of my head so i probably missed something.

cheers,
jamal

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 5 Mar 2004 13:23:14 -0800

Alex,
 
We will need some of the stuff below to run ForCES directly over L2
including reliability/CC, etc.
But that doesn't mean all this complexity has to necessarily be
implemented by the ForCES protocol.
See David's email on this issue, we might land up using TIPC to provide
some of this functionality over L2.
This still needs to be discussed.
 
Regards
Hormuzd

-----Original Message-----
From: Alex Audu [mailto:[email-masked]] 
Sent: Friday, March 05, 2004 1:04 PM
To: Khosravi, Hormuzd M
Cc: [email-masked]
Subject: Re: [Forces-protocol] RE: ForCES Protocol Analysis Design Team
Administrivia

Hi Hormuzd,

If ForCES run directly over L2, we are suggesting it acts like the
network (OSI) or 
Internet layer (IP). That means it validates, routes, and demultiplexes
amongst various
transports/applications  (amongst other functions). Is that what we want
here?

Regards,
Alex.

I believe layer 2 protocol is the same in both models (internet and

OSI).

Common example is Ethernet. May be the use of the word "interconnect"

was confusing.

What I mean is that the ForCES protocol should be able to run directly

over layer 2

protocols like ethernet. This might be useful in some in-box scenarios.

Let me know if you have any other questions.

Regards

Hormuzd

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

Sent: Thursday, March 04, 2004 12:56 PM

To: Khosravi, Hormuzd M

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

Administrivia

Hormuzd,

I don't understand this requirement (reproduced below):

------------------------------------------------------------------------

The ForCES protocol will run directly over layer 2 interconnects. It can

either use additional TLVs or encapsulation headers or transports such

as TIPC to provide the missing functionality such as reliability,

fragmentation, etc.

------------------------------------------------------------------------

Can you explain this?  Which L2 are you refering to? (Internet Protocol

layer 2 or OSI layer2). 

Regards,

Alex.

  

Here is a starter list of common high level ideas/features/principles

that I believe we all agree on...

All ForCES protocol messages should consist of a fixed size header and

variable size payload fields. Further, the protocol header is made up

of

CE ID, FE ID fields in addition to other fields (TBD)

All ForCES protocol messages should be 32-bit aligned.

The ForCES protocol payload consists of a number of variable size TLVs

i.e. all ForCES messages must use TLV encoding.

The FE ID field in the protocol header is assigned or allocated by the

CE.

The ForCES protocol/model must support the discovery of static

capabilities of an FE. The protocol/model may also support dynamic

capabilities when they are supported by the FEs.

The ForCES protocol should support logical addressing for multicast in

addition to unicast. The FE ID, CE ID fields in the header will be used

for addressing FEs, CEs.

The ForCES protocol should have separate channels/connections/(any

other

terminology ?) for data and control messages. By data messages we mean

control protocol packets such as OSPF, RIP packets, etc. which need to

be redirected from FE to CE or forwarded from CE to FE. By control

messages we mean all other control/capability/configuration messages.

The ForCES protocol will mandate a minimum set of transports for data

and control connections/channels for interoperability reasons.

The ForCES protocol will take advantage of underlying transports/

interconnects to provide features such as reliability, security to keep

the protocol design itself simple.

The ForCES protocol will run directly over layer 2 interconnects. It

can

either use additional TLVs or encapsulation headers or transports such

as TIPC to provide the missing functionality such as reliability,

fragmentation, etc.

This is just a starting list, we should continue adding to this one as

we discuss more ideas.

Pls feel free to give comments or make any changes to the text above.

BTW note to the list-admin, [email-masked] address is not working.

Regards

Hormuzd

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

Sent: Tuesday, March 02, 2004 4:55 PM

To: [email-masked]'

Cc: Putzolu, David; [email-masked]; [email-masked];

[email-masked]; Steve Blake; Robert Haas;

[email-masked]; [email-masked]; Wang,Weiming; Patrick Droz;

jeff pickering; [email-masked]; Deleganes, Ellen M; [email-masked];

[email-masked]; [email-masked]

Subject: RE: ForCES Protocol Analysis Design Team Administrivia

Hi Jamal, All

all agree on.

regards

Hormuzd

[email-masked]