Subject: RE: [Rfid] Re: Rfid Digest, Vol 6, Issue 9

From: "Scott Barvick" <[email-masked]>
Date: Tue, 22 Mar 2005 21:57:35 -0500

The posts and lengthy debates in other forums on the XML vs. binary issue lead me to see if we can't try to find a way through this that does not rely on any particular 'religion' on the subject.   
 
The key goals for the reader<-> client protocol effort discussed in the BoF are:
1) Overall support of operations of large numbers (<=1000) of readers in a facility
2) Specific support for coordinated read and access operations for this number of readers in a facility 
3) Support for the full exposure of capabilities associated with multiple and varying air protocols.
 
These are goals that are unique to this particular IETF effort, but the idea is that if you are contributing to the list, you think it is the future.   I think we need to look at these specific goals, and figure out what the protocol looks like that will achieve them.  
 
If the XML pops out as being able to support the requirements, then we should use it because it could speed development time and aid debugging.  If we find that we won't be able to put a real XML parser on a device that is expected to be one of 1000 other readers in a facility or we don't want to allocate the extra network bandwidth to turning binary tag data into a specific XML character set, then we have the binary answer.
 
Can we proceed by doing some analysis on the above requirements in the context of each style of protocol?
 
Scott

________________________________

From: [email-masked] on behalf of Larry Martin
Sent: Tue 3/22/2005 12:40 PM
To: [email-masked]
Subject: [Rfid] Re: Rfid Digest, Vol 6, Issue 9

Hello -

Most people expect a binary protocol, and assume it will be faster;
however, we all have had experience with packing, byte order and other
issues making it difficult to maintain binary protocols.  Besides making
it difficult for engineers, these issues make life hard for users when,
for example, new server code makes it impossible to talk to client nodes
until all clients are updated locally.  XML, as a tagged protocol,
provides many synch points which software can use to parse incoming
messages, making a more fault tolerant overall system.  As a human
readable protocol, XML allows quick startup of engineering efforts,
i.e., you don't have to write new PC software to debug the embedded
interface.

As the former lead programmer for SAMSys, I designed and implemented a
human readable HDLC protocol with tagged syntax for SAMSys' line of
multifrequency, multiprotocol readers.  It's called CHUMP, some readers
may be familiar with it.  It has been criticized for wasting serial line
bandwidth, but nobody has ever convinced me that the protocol per se was
the source of any bottlenecks.  To be fair, the processing overhead of
text-binary conversion does slow things down on the slower targets (we
started out with PIC processors), but those slower targets are also free
to implement a subset of the protocol.

By using a human-readable protocol, SAMSys was able to concentrate on
embedded development during the early years, and was not distracted by
the vagaries of programming for the various flavors of Windows and
Linux.  To be fair, again, SAMSys has been able to get by without a
Windows API or application software, and that has made it harder for
some integrators to adopt their devices (that is a whole separate
discussion).

I think this group should carefully consider specifying a human readable
protocol, and look forward to discussing the issue with the group.

Regards,
Larry Martin
www.GlueLogix.com
Embedded System Consulting Including RFID

>>What do we want for a reader protocol?  I would propose that you want a
>>efficient, simple-to-implement protocol that rides over a well known
>>transport.  The readers are going to vary from very simple Ethernet powered
>>devices to PC Cards in a laptop to hefty systems with lots of memory and
>>compute power...a wide range from multiple manufacturers.
 >
> [snip]
 >
>>Krishna's draft (draft-krishna-slrrp-01.txt) goes into great detail on one
>>example over TCP using traditional binary protocol techniques.  My
>>understanding is that the EPCGlobal data definitions have been defined in
>>XML (please correct me if I don't have that right).  So, are there other
>>possibilities that should be considered?  Should the XML just be plopped
>>into TCP byte streams?  Are the gains in using XML worth the overhead?
>>Thoughts? Opinions? Options?
>>   Eric
>
>
>  I am not clear about what you meant by EPCGlobal data definitions in XML? They have
>  couple of protocols that use XML encoding. I dont think there are any 'data' defined
>  in XML.
> 
>  XML is 'cool' and has benefits, such as extensibility and human readability.
>  I dont think human readability is a goal or requirement for this reader protocol. I have
>  my opinions regarding xml and extensibility especially in the reader-protocol space. I just want
>  to make one point that XML is not magic - it does not automagically enable extensibility.
>  Extensibility is achieved when both parties on the either side of the link implement the changes
>  in XSD associated with the XML changes - how different is it from binary codes that are agreed upon
>  by both the parties. 
> 
>  I would like to hear what other people have to say about this issue.
> 
> Thanks,
> /Krishna
> 

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: Howard Kapustein <[email-masked]>
Date: Wed, 23 Mar 2005 16:06:47 -0500

>These are goals that are unique to this particular IETF effort
 
If by that you mean these are goals for the IETF but not EPCglobal
respective workgroups, I respectfully disagree.

#1 is a goal for 'everyone' involved in this stuff, though (all)
quantifications of "large numbers" are somewhat debatable.
 
Last I saw, #2 is considered a goal for EPCglobal's workgroups but not a
(top) priority based on user feedback. Walk before you run. People find this
to be important but not (as) significantly pressing vis a vis other issues,
hence it's on-the-radar but not front-of-the-queue. [It's not all Apocalypse
Now either -- there are effective mechanisms to address this in the short
term, far more so than some other issues. Hence, priorities...]

#3 is different.
It's not a current priority for EPCglobal's Reader Protocol workgroup, as
users and vendors (hosts, readers and middleware) were more interested in a
common protocol and a degree of abstraction.
 
Given the complexity of trying to define what amounts to low level and
implementation level standardized configuration settings and controls
coupled with the...youth of the industry and implementations and products
and industry knowledge and understanding of usage and needs...EPCglobal's
Reader Protocol group is not (at this time) focusing on commands to
micro-manage the reader's implementation (e.g. how it drives air protocols).
 
This is *the* fundamental difference between EPCglobal RP and IETF SLRRP, as
I've seen them to date.
 
RP is intentionally targeting a higher level of abstraction at this time,
reader vendors are comfortable with the level of detail not going too deep
(they feel they have their needed room to innovate in creative ways) and RP
provides a 'vendor extension' mechanism whereby non-standard extensions can
be provided in a standard way (either for oddball or 'innovative' reasons,
or those who produce nifty innovations predating standardization).
 
SLRRP is targeting a much lower level of detail for standardization.
 
I have reservations about the merits of this approach.
 
Quite simply, do you control the amount of fuel your car's fuel injectors
allow to flow while you drive?
Or do you just stick the key in the ignition, put it in gear and use the
gas+brake pedals?

I can think of good reasons why this low level of information+control is
useful, but to an exceedingly small # of people, and even then it's an
incomplete solution. In time, rabbit. In time... but don't you think it's
more important to tackle the overwhelmingly major issues first with a sound
foundation that can be extended to such things, rather than try to tackle
everything day one?

And notice I've said RP *at this time* plans to effectively target the word
processor (or at least notepad.exe) level of functionality, and not the low
level sector editing and raw disk io commands. Walk before you run. No
reason why EPCglobal RP can't add these lower level constructs -- it's been
discussed in the past, and the design is extensible to accomodate such
additions if desired, it's purely been a matter of priorities so far. Quite
frankly, there hasn't been a lot of interest to date in this level of
functionality, so we've focused on the more important and urgent features
first.
 
This isn't to say RP entirely eschews such details.
RP takes a more 'host' (non-reader) view of the command protocol so far --
what would someone outside the reader need to know and care about, given the
current and emerging degrees of reader sophistication (no one sells an
antenna wired to 10BaseT jack with *nothing* between) and work to
standardize that. There are *some* details that are important, but frankly
far fewer than you think, and all parties so far have viewed this minimal
set of controls as effective and reasonable.

I could relate horror stories I've personally witnessed trying to get people
to agree on RP's level of detail, forget anything more involved. If you
expect to deep dive several layers past this *AND* have a real 'standard'
that people embrace and use, I think you're greatly underestimating the
task.
 
    - Howard
 
P.S. Well, no, I probably can't relate those horror stories. But I can show
you the scars they left behind :-)

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Scott Barvick
Sent: Tuesday, March 22, 2005 9:58 PM
To: Larry Martin; [email-masked]
Subject: RE: [Rfid] Re: Rfid Digest, Vol 6, Issue 9

The posts and lengthy debates in other forums on the XML vs. binary issue
lead me to see if we can't try to find a way through this that does not rely
on any particular 'religion' on the subject.   
 
The key goals for the reader<-> client protocol effort discussed in the BoF
are:
1) Overall support of operations of large numbers (<=1000) of readers in a
facility
2) Specific support for coordinated read and access operations for this
number of readers in a facility 
3) Support for the full exposure of capabilities associated with multiple
and varying air protocols.
 
These are goals that are unique to this particular IETF effort, but the idea
is that if you are contributing to the list, you think it is the future.   I
think we need to look at these specific goals, and figure out what the
protocol looks like that will achieve them.  
 
If the XML pops out as being able to support the requirements, then we
should use it because it could speed development time and aid debugging.  If
we find that we won't be able to put a real XML parser on a device that is
expected to be one of 1000 other readers in a facility or we don't want to
allocate the extra network bandwidth to turning binary tag data into a
specific XML character set, then we have the binary answer.
 
Can we proceed by doing some analysis on the above requirements in the
context of each style of protocol?
 
Scott

  _____  

Hello -

Regards,
Larry Martin
www.GlueLogix.com

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid
<https://www1.ietf.org/mailman/listinfo/rfid>

---

From: "David Husak" <[email-masked]>
Date: Mon, 28 Mar 2005 12:59:12 -0500

Hi Margaret,

I am indeed familiar with an application that uses multiple readers to
servo a process that requires the control to loop through a server
function. It's in a heavy manufacturing operation, and the timeliness
requirements are modest, on the order of a couple of seconds. I'll offer
that _my_ definition of "real-time" is irrelevant, perhaps I should have
used the word "on-line." 

The larger point that I was trying to make was that we should not
confine our discussion to a set of applications in a particular user
community. In fact, there are a number of industry-specific consortiums
for developing (inter-)application IT standards including EPCglobal and
VICS in retail, IATA for airlines, CIDX for chemical manufacturing,
RosettaNet for electronics manufacturing, to name a few. They will all
have something to say about how RFID will be applied in their respective
constituencies.

The opportunity before us is to recognize that as the technology is
maturing and scaling, readers are IP-connected devices that play a
variety of roles in a variety of applications satisfying a range of
requirements (wrt RF environment, spectrum utilization, latency,
accuracy, security, authentication, online v. offline behavior, etc.),
and to define and/or apply protocols necessary to underpin them all, or
at least as many as we think we understand :).

BTW, you are absolutely correct, in control-system applications where
latency requirements are strict and sub-second, like your example of
controlling diverters on a conveyor belt like in a CPG distribution
center, the right answer is to servo the operation locally within the
reader or via a PLC. It's noteworthy, however, that even this
reader/system can't operate offline for too long, since it has to know
which tags are to be diverted at which gate...

Dave

------------------------
David J. Husak
Reva Systems Corporation
[email-masked]

 -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Friday, March 25, 2005 11:13 AM
> To: David Husak
> Cc: [email-masked]
> Hi David,
> >For retail and CPG inventory tracking applications, you are correct.
> >There are however, applications of RFID that use the data produced to
> >servo real-time controls and processes. These applications should be
> >supported as well.
> 
> Do you know of any cases where tag data is used for real-time control
> of a device (such as a diverter) where the tag data goes back to a
> central (multi-reader) controller that that central controller issues
> a command to the device (i.e. the diverter) under real-time control?
> What is your definition of real-time in that application (accuracy in
> milliseconds?).
> 
> In most cases, I have seen real time control accomplished locally,
> via a GPIO line on the reader that is triggered based on tag data
> and/or via serial line communication with a host device (in the
> embedded case).
> 
> Margaret