Adrian,
Concur with your counterpoints, 99.98 percent on a normal day :))
Perhaps 'overspecifying' BER is not a good idea. On the other
hand, 'underspecifying' BER is a good idea either.
IMHO, this issue will come eventually come full circle, and based
on experiences in the 'school of hard knocks', not specifying
a requirement (especially a critical one), is (ahem, ahem)
"a tactical solution which will negatively influence the strategic
objectives".
At least, miminal BER numbers should be specified as 'best estimates'
to give all professionals in the field a vector to steer toward,
and a common frame of reference of discussion.
Sorry for the 'motherhood and apple pie' counter-argument, which is
not a fair basis for debate. My voice is but one, and I don't wish
to distract the WG with my zeal for engineering requirements.
Regards!
Tim
>
> The fact of life is that space links *are not* fiber links -- "when they're
> good they're very very good, but when they're bad they're horrid". Many of
> us feel that a more robust solution would be a local approach which
> exploits the fact that we generally have very clear indicators when the
> space link is going south. Providing some inter-layer signalling whereby
> the space link can tell TCP "hey, that loss wasn't congestion, it was a
> fade" may not be a bad idea at all. With such an approach, the TCP
> retransmission control becomes an extension of the FEC, not an independent
> entity.
>
> Best regards,
> Adrian J. Hooke
> NASA-JPL
>
> At 12:27 PM 98/03/28 -0500, Tim Bass (IETF) wrote:
> >So, I highly suggest that this WG formalize the requirement
> >that the TCPSAT group expects a certain BER over a certain
> >time period (or a table of these requirements)
>
-- Tim Bass [email protected] [email protected]
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST