[Forces-protocol] Re: Progress issue 1: packet encoding

[Jamal Hadi Salim <[e-mail]>]

This is a common trick. I thought both FACT and GRMP have it.
Netlink2 for example has a special command for errors.
The body will contain an error code and the offending original
header (similar to ICMP source quench).

These are issues we can settle. Can we please close topic 1?

cheers,
jamal

On Tue, 2004-03-09 at 11:04, Alex Audu wrote:
> On Issue 1: packet encoding,  it is easy to come to concensus on this
> one.  So far, the train 
> thoughts is per the attachment to this e-mail.
> 
> Issues raised:
> 1) Avri raised issue of indicating an error with an error flag on the
> header.
> 
> Comment:  That is certainly one way to convey error conditions. But
> experience has
> shown that if you do that, you force your protocol software to check
> this flag for every
> message that comes in (to ascertain if it is error message or not),
> before proceeding. This
> is an incredible  wate of processor cycles since an error condition is
> really an exception 
> condition. 
> 
> Carrying an error indication with an error TLV is much better.   It is
> like an error color
> code; you only do error processing if that color shows up.  And all
> the other messages
> are handled similarly.  This could easily be the difference between a
> protocol  that is
> twice as fast and efficient  compared to an otherwise poorly designed
> one.
> 
> Regards,
> Alex.
> 
> 
> 
> 
> Jamal Hadi Salim wrote:
> > On Tue, 2004-03-09 at 01:42, Putzolu, David wrote:
> >   
> > > Avri wrote >
> > >     
> > > > I have a general question about headers, is there any feeling in this 
> > > > group that a common header could not be arrived at.  If not then we 
> > > > could move on to other issues.  The reason I ask is that one 
> > > > can spend 
> > > > a whole lot of time fine tuning a header to be just right.  If there 
> > > > are as of yet unresolved issues on the header, can anyone list them?
> > > >       
> > > 
> > > I agree with Avri, 
> > >     
> > 
> > On the one hand i wanna say lets skip so we can make progress.
> > OTOH, I am a little worried that the gaps in point of view
> > are so huge that this will cause problems later. 
> > The only way we can close faster is if ontopic emails are addressed in
> > the fastest possible way.
> > 
> > On a personal level i am trying to prioritize responding to things
> > on this list. But sometime i get a little discouraged. Example my last
> > emails on topic 0 and topic 1 have not been responded to for at least
> > 24 hours. Actually they have been a response which happens to be off
> > topic. This worries me because i dont think we will make the deadline.
> > If theres 10-12 serious issues and we have about 10 days to go
> > AND we havent closed a single issue up to now --> theres _no way_ 
> > we can meet the deadline. We need to close 2 issues a day.
> > 
> > Of course a brute force solution is to say theres desire to reach a
> > compromise and stop there. But this in itself is dangerous and i
> > would not prefer to go that route.
> > 
> > So at the moment i am at a loss. Maybe the approach of listing issues
> > which need to be agreed on is not the right one? What thoughts do people
> > have on this? Other proposals that have been made so far that received
> > no traction are:
> > a) each protocol draft to list what they cant live without,
> > b) Each protocol draft to list their implementation experiences and
> > say what they found useful and what wasnt.
> > 
> >   
> > > and like others I am having a hard time 
> > > keeping up with all the different discussions.  
> > >     
> > 
> > Yes, this has been an issue but is general to any email or usent
> > discussuions - problem is someone starts going off 
> > topic then other people respond. And the cycle continues. 
> > 
> > The best way to run "meetings" over email are:
> > 
> > Rule 0: have an agenda (list of topics to discuss). We have this
> > Rule 1 is to have a running topic (eg currently issue 1 and 0 are
> > ontopic). No other topic is to be discussed. We are trying this.
> > Rule 2 is not to respond to currently-offtopic emails. This is typically
> > the easiest rule to break on email or usenet because of human nature.
> > Naturally this has been the most broken rule. 
> > Rule 3 is once in a while people need to be reminded they are off topic.
> > (I have tried to do this in personal emails as well as on the list.)
> > Rule 4 is if the content does not reflect the subject line, change the
> > subject line (like i just did with this email).
> > 
> > I could almost say we are getting close to following the above; I
> > counted and only 2 emails were offtopic out of last 6 as opposed to
> > 6 out 10 before that.
> > 
> > cheers,
> > jamal
> > 
> > 
> > _______________________________________________
> > Forces-protocol mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/forces-protocol
> >   
> 
> 
> ______________________________________________________________________
> 
> I don't know what the flags could be used for. The TypeID could be used for
> siganling the type of data encoding explicitly,  (i.e. XML, ASN.1 etc).
> My preference will be the following.
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                     0               1               2             3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |vers   |eType  | prio| reservd |  msgClass     |   msgType     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       message length                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Source xID           | Destination xID               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Sequence Number                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      
> 1) version # indicates the version of the protocol.
> 2) the type of encoding comes next.
> 3) the priority of the message comes next.
> 4) the command has been divided into message class and type to ease management and handling.
> 5) the source and destination are now both 16 bits each. This allows up to 64K FEs. That is cool!
> 6) the length is now 32 bits long. This will accommodate flow measurement messages which
>    tend to be huge,  from FE to CE.  It will also accommodate large table dumps from CE to
>    FE.
> 7) then comes the sequence number.
> 
> Any comments?
> 
> Regards,
> Alex.
> 
> > Jamal,
> >
> > Before I give my comments, I would like to say that I appreciate the
> > fact that you did not copy/paste the netlink header from your draft over
> > here! That is a very positive sign to me, lets try to stick to the best
> > technical solution rather than pushing our own protocol implementations.
> > That's the best way to make progress on this merger!!
> >
> > Here are my views on this issue, particularly the common header:
> >
> > Command: Agree this is needed. We think 8-12 bits will be more than
> > sufficient for this depending on whether it is subdivided. We have
> > sub-divided this field into Class/type...this is an OO approach, seemed
> > pretty neat. However, I am personally fine with having a single field
> > for this, no problem with that.
> >
> > Length: Agree needed and agree with size.
> >
> > xIDs: Agree this is needed. More detailed comments on length, semantics
> > in my previous email.
> >
> > Sequence No: Agree needed and agree with size.
> >
> > Flags/Priority: We need 2-3 bits for priority in every message. I don't
> > think we need any other flags in all messages.
> >
> > Typeid: This is one field I don't think is needed in all messages. I am
> > not sure why this is needed at all cause, we will be using the Model and
> > LFB IDs to address processing functional blocks on the FEs.
> >
> > Missing field: Version (2-4 bits): This is present in all protocols, and
> > is generally included in most IETF protocols. Its usually the 1st field.
> >
> > General comment: Lets try to be stingy on the size of the header and its
> > fields since this will be included in all ForCES messages.
> >
> > Jamal's text.......
> > The Forces Message Header:
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >                     0               1               2             3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |             Command         |               Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                          Source xID                           |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                        Destination xID                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                        Sequence Number                        |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |             flags           |             typeid              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> > XML encoding:
> > XML encoding may be useful in capabilities definition
> > (i.e slow path) but not in the configuration of data path tables.
> > This is because of its nature to require higher bandwith and
> > CPU computational needs.
> >
> > HK Comment: I think we should stick with a single encoding type, namely
> > TLV. This is also what some of the model team folks have mentioned
> > before for the protocol. Is there a reason why capabilities cannot be
> > expressed using TLVs?
> >
> >
> > Thanks
> > Hormu


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