<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:Arial;
        color:navy;}
@page Section1
        {size:595.3pt 841.9pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
        {page:Section1;}
-->
</style>
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Just a follow up. Looking at this again I
think it is actually important that we do not use TCOA as a justification for
TCONS…..that would be open to the criticism that we are artificially creating
our own need for TCONS.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Chris.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
sois-tcons-bounces@mailman.ccsds.org
[mailto:sois-tcons-bounces@mailman.ccsds.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>dstanton@keltik.co.uk<br>
<b><span style='font-weight:bold'>Sent:</span></b> 01 April 2005 13:06<br>
<b><span style='font-weight:bold'>To:</span></b> sois-tcons@mailman.ccsds.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> [Sois-tcons] TCONS
rationale</span></font><span lang=EN-US><o:p></o:p></span></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'><br>
My initial thoughts were to look to the TCOA documentation to find the services
which they are demanding of the underlying transfer layer and which are not
provided by current transport services. However, there isn't much to be got
from their documents.<br>
<br>
We need to identify very succinctly the TCONS USPs (Unique Selling Points) in
bullet form and to identify the arguments for and against existing protocols
which may already have them. So, a first cut would be:<br>
<br>
Bit efficiency (arguments about IP header compression etc.)<br>
Priority (does Diffserv do the job?)<br>
Scheduling (Why?, Which applications?)<br>
<br>
The fundamental arguments against are likely to be (and I'm playing devils's
advocate here):<br>
<br>
Are we really likely to need to have to provide these services across
hetereogeneous busses? Are we compensating for bad spaceraft design and
(flameproof suit on) the failure of OBL to arrive at a standardised bus/LAN?<br>
<br>
Are these services actually required by real applications? <br>
<br>
Can these services be provided by other transport/network layers?<br>
<br>
Can these issues be solved by using conventional protocols across high capacity
busses? The space link guys have the laws of physics working against them. We
don't have such an excuse for having limited bandwidth. Do the power or
availability of rad hard devices arguments wash? If we have spacewire why are
we worried about bit efficiency and priority?<br>
<br>
Fundamentally we are missing a SOIS concept of operations and policies (one
such policy issue is why are we prepared to be iconoclastic at the network
layer and yet pander to entrenched positions at the bus/lan level, trying to
accommodate every flavour of bus that has ever flown or likely to be flown).
Looking at the documentation, ther's a lot of assertion without much in the way
of justification. This may be because I haven't seen some of the earlier work.<br>
<br>
I'm not trying to shoot everyone down here. It's just that if we aren't clear
in our own minds on these issues, it will be very difficult to defend
TCONS/SOIS at the CESG. <br>
<br>
Any thoughts?<br>
<br>
Dai<br>
<br>
<o:p></o:p></span></font></p>
</div>
</body>
</html>