Subject: RE: [Forces-protocol] issue 1: packet encoding

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 8 Mar 2004 21:39:11 -0800

Alright, thanks for this correction.
However, we do have a use for priority bits at the ForCES layer, its
present in all the proposed protocols in some form and is part of the
ForCES Requirements RFC section 6 #5. We initially had this as a 1 bit
field however we received feedback from several WG members to increase
the no. of bits to allow prioritization of different traffic on the data
channel.

Hormuzd

-----Original Message-----
From: Putzolu, David 
Sent: Monday, March 08, 2004 2:07 PM
To: Khosravi, Hormuzd M; [email-masked]'
Cc: [email-masked]'
Subject: RE: [Forces-protocol] issue 1: packet encoding

[hat off]
Hormuzd wrote > > >
Jamal wrote > >
Hormuzd wrote >
> > > Flags/Priority: We need 2-3 bits for priority in every message. I
> > > don't think we need any other flags in all messages.
> 
> > Also in regards to priority; do you see this being used all the
time?
> 
> [HK] Sure, this is definitely needed in all messages. I believe even
> GRMP has this, infact I had a feeling till today that even netlink had
> it.
> 
> > and would an underlying transport priority be insufficient
> > (example diffserv, 802.1p etc)?
> 
> [HK] This is priority at the ForCES level which will eventually be
> mapped to the underlying transport/interconnect. We definitely need it
> at the ForCES level as well.

I don't understand the priority bits.

Priority bits in a header are not used to signal lower layers,
they are used to signal at the layer the header is processed.
Thus a router might look at the DS byte, but it ignores the 
TCP URG flag. An Ethernet switch looks at 802.1p prio bits, but
ignores the DS byte. Etc.  Doing otherwise is a serious 
layering violation.  

The way you signal the networking stack in an application
is via software APIs, not bits in a header - in Windows that
is the WSAIoctl(SIO_SET_QOS) API.  In Linux I think netlink APIs
are used (not sure, Jamal probably knows). The kernel never
looks at the data you pass over via write(), which is where the
ForCES header would be delivered to (TCP|UDP|whatever).

Unless you expect the ForCES daemon/agent on the other end of
the connection to behave differently in the presence of these
priority bits (how?) they have no use.

-David

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 9 Mar 2004 22:53:27 +0800

> Hi Jamal,
>
> Could you just add some tag to indicate your reply? Or else, I have to help to
> add it so that others can see your reply. Some comments as below.
>
> Thank you.
>
> Weiming
>
> ----- Original Message -----
> From: "Jamal Hadi Salim" <[email-masked]>
> To: "Wang,Weiming" <[email-masked]>
>
> > Weimimg,
> >
> > On Mon, 2004-03-08 at 08:55, Wang,Weiming wrote:
> > [..]
> >
> > > 1. The "command" field
> > > This is really a field that confuses me. The confusion is:
> > > 1) If it is a field only with command "Add/Del/Get", I suppose we can just
> > > obsolete it. The command can be surely be expressed in the followed body
> > > by using TLVs.
>
> >[Jamal Re:
> > Every message will have a command. For that reason it belongs to the
> > main header.]
>
> [Wang Re: I would say it is also possible to have a message contain more than
> one command. But I don't want push this too hard so that we may be quicker to
> reach an agreement.]
>
> >
> > > 2) If we keep it, I'm afraid its meaning should be far from these. For
> > > example, how an event report can be represented, and how a command bundle
> > > is represented then, and many others?
>
> >[Jamal Re:
> > I will explain how we implemented events; note, this is different from
> > the current command structure but shoudl give you a view:
> > - An "add route" from CE->FE means to configure something on one or more
> > FEs that are addressed.
> > - An "add route" from FE->CE is an event notifying that a route was
> > added.
> >
> > An alternative is to reserve one bit for saying its an event or
> > configuration then you dont have to intepret directions.]
>
> [Wang Re:
> Why not just let us use an "Event report message" instead of using such a "add
> route" along with some bit to say it is an event, while leaving the "command"
> field from being fully used.]
>
> > > We just think to have a field  with insufficient functions really makes
> > > confusions.
> > > As a result, I suppose two solution schemes for this problem:
> > >
> > > Scheme 1: Define this as "message type", to have the message body to
express
> > > the operation not just based on TLV format. This means things like "Flags"
> > > "operating fields" are explicitly expressed according to the "message
type"
> > > operation requirements. Remember that by using this scheme, we have
already
> > > taken the whole ForCES message as one TLV.
> > >
> > > Scheme 2: Not define anything in the header on the "command" or
> > > "message type", leaving things defined in the followed body, while the
body
> > > is expressed by a set of TLVs, each TLV representing a type of operation.
> > >
> > > The advantage for Scheme1 is it is very clear in semantics and saves bits
> > > quite a lot.
> > >
> > > The disadvantage is it has to define a specific message type for
> > > command bundle.
> > >
> > > The advantage for Scheme 2 is it is easy to implement command bundle,
> > > but the disadvantage is it costs more bits and makes protocol header less
> > > to do.
>
> >{Jamal Re:
> > I prefer to have the headers with flags; flags were usable on every
> > message. ]
>
> [Wang Re: not very sure how your reply maps what I said.]
>
> >
> > > 2. The Checksum field and other error control mechanism
> > > One essential function a protocol header takes is for a reliable
> > > information exchange, therefore, the common error control mechanism should
> > > be included in the header instead in the body.
> > >
> > > It seems no argue that a checksum should be provided as an option.
> > > Only difference between the candidate protocols is how it should be put.
> > > GRMP puts it at the protocol message end, Netlink2 has it as a TLV, I
> > > suppose FACT also intends the same. I'm thinking the purpose to have it as
> > > a TLV is mainly trying to reach a uniform TLV format. What we argue is to
> > > put checksum in a TLV may get more loss for the checking function, because
> > > it then will be in a risk that the TLV structure itself may be erred,
> > > which may result in the invalidation of the checksum.
> >
> >[Jamal Re:
> > Netlink2 has the concept of several shades of reliability.
> > Some messages dont need to be validated and therefore dont
> > need a checksum. This is also the path we are following now,
> > for that reason checksum should stay an optional field.]
>
> [Wang Re: checksum in GRMP is also optional, my opinion is it has better
> performance to optionally put it at the message end, just the same as UDP.]
>
> >
> > > GRMP reuses the idea "result" and "code" from GSMP, I'm sure this
> > > error control function should be included in the protocol. As the protocol
> > > header takes the tasks for a reliable information exchange, I
> > > strongly suggest it is put in the header. Could other candidate team
> > > show your opinions or solutions to this?
> >
> > [Jamal Re:
> > We had the concept of an ACK which returns results.
> > Depending on the result, this could be considered a NACK.
> > The ACK is requested per message using flagd and so sometimes may never
> > be sent. Again this has to do with levels of reliability.
> > In other words while the result is useful in the header,
> > it is only useful when the result is requested.
> > This is described in the section " The ACK Netlink2 Message".
> > I think this is similar to the way you do it in GRMP.
> > ]
>
>
>