I was getting up to speed on the updated white-papers http://dvjames.com/esync/dvjRate2005Aug30.pdf and have some comments and questions which I hope will be useful.
I recall at some point there was a suggestion that with no shaping in place worst-case end-to-end and peak-to peak delay would increase exponentially with number of hops. My understanding at the moment was that shaping was to make this linear. Both Mr. Garner's simulation http://grouper.ieee.org/groups/802/3/re_study/material/garner-050822-sim-multi-hop.pdf and updated paper both suggest that delay would in fact be linearly-dependent on the number of hops. Since consensus seems that with or w/o shaping delay is linear, what exactly are we trying to gain by applying shaping? Reduce the linear coefficient?
If we are in fact trying to reduce dependency coefficient and associated latency figures (steepness of the dependence graph), then it seems that shapers would have to be synchronized across the network to guarantee that at no time our packet will not experience an unfortunate situation where each hop puts it last in the line of packets incoming from other ports (I assume output queue router for example). It seems to me that unless streams and/or shapers are synchronized across the network there will be no way to avoid such collisions, but this basically brings us to a fully isochronous model.
On the other hand if we're willing, while staying within reasonable latency figures, to switch hard guarantees to a statistical guarantees, then we could conceivably get away with some soft-isochronous model (or pseudo-syncronous as it is called in the paper).
It seems a bit unclear from the paper, what are the prime reasons for not going with a straight isochronous model? There are number of existing isochronous Ethernet technologies we could look at as an example (i.e. PowerLink).
Regards,
Max Azarov.
David V James <dvj@ALUM.MIT.EDU>
08/31/2005 01:19 AM
Please respond to David V James
To: STDS-802-3-RE@listserv.ieee.org
cc:
Subject: [RE] Updated paper
All,
I have posted an update for tomorrow's meeting.
This can be found at:
http://dvjames.com/esync/dvjRate2005Aug30.pdf
I assume Michael will move this to the group's
IEEE web pages.