Keith,
Thanks for your detailed comments on the draft red book. I will read through
them and get back with anything that I disagree with or don't understand.
I have also had some general, but very pertinent, comments from Rick when we
met at the SpaceWire Working Group meeting at ESTEC.
Rick would like to see an overview at the start i.e. a stack diagram and
description.
Rick also thought that the network layer API should not be revealed as a
service to the user.
I though that these were both good suggestions and will update the document
accordingly.
Other comments not directly related to CCSDS SOIS have convinced me that a
primitve means of communicating on a local bus is also require to be
specified. This was formerly the LODI service that was discuss a couple of
years ago in SOIF. The SpaceWire Working group are working on a suitable
protocol which could be generalised to cover other buses. I will write
something up about this for TCONS and include it in the next revision of the
red book for comment.
The Scheduled Delivery service still has to be written up.
Regards
Steve
-----Original Message-----
From: Keith Scott [mailto:kscott at mitre.org]
Sent: 06 October 2004 19:12
To: 'Steve Parkes'
Cc: sois-tcons at mailman.ccsds.org
Subject: RE: [Sois-tcons] TCONS Red Book Draft
Steve et. al.,
Below are my edits. I found it easier to just edit the document with track
changes turned on, so I have attached the modified document as well.
--keith
==================
Page 19, first bullet under the three levels of service provided by TCONS:
where the text says that the best effort service makes a single attempt to
deliver data to the destination. Suggest something like "...will attempt to
deliver data to its destination but makes no guarantee of success." The
point is that the best-effort service doesn't guarantee delivery. If
somebody wants to implement the best effort service in such a way that it
sends TWO copies of everything, let 'em.
Same paragraph: Instead of 'packets with higher priority are sent
before...', I'd suggest something more specific (similar to what appears
later in the document) like 'Whenever packets are transmitted or forwarded,
packets with higher priority are...'
Same paragraph: There should probably be something like: 'The best effort
service makes no claims with respect to duplicate delivery, or the order in
which packets are delivered.' The order claim contradicts later text, so
some resolution needs to happen. We may specify that packets are forwarded
in priority order, but still get out-of-order delivery at the destination
(consider two packets of the same priority that take two paths -- one fast
and one slow, e.g.).
Second bullet: Arrival of data is signalled to the source. Instead of
source: "transport layer (agent)?" Again the suggestion for stronger
language like 'at each router, whenever packets are queued, segments with
higher priority...'
Third bullet: 'A source can send to one of several possible destinations in
any particular time slot.' After thinking about this for a while I think I
get it, but maybe some extra text along the lines of the following to
clarify? "Time slots may be allocated so that there are several 'paths' (in
time and space) that start with a particular slot and source, from which a
set of destinations can be reached. In this case the source can use its
single slot to send to any of the destinations."
Section 3.2.1 "data sent from one End System to another..." I think we
should be really clear about what the communicating endpoints are. For
example, is an 'end system' a particular machine, an application, ... I
think we're really talking about applications (things above transport)
communicating with each other, and may need to say so explicitly.
Still 3.2.1: near the end of this paragrah there's the stronger language
about forwarding: "High priority packets are sent and forwarded before lower
priority ones."
The statement '...similar to UDP except that TCONS supports packet
priority.' is wrong. IP supports priority (either through TOS or diffserv)
and this carries to UDP.
Page 21 in the list of "The Best-Effort service has the following features"
Statistics about errors and undelivered data. Who keeps statistics about
undelivered data? If something is lost due to a checksum error at the data
link (say), TCONS will never know about it.
The next paragraph is the first place that 'port' shows up. If we have some
clear definition of endpoint, we might want to put in some verbiage about
ports as well.
The whole notion of putting received data into 'the first buffer for which
it is destined' may be a problem, especially if we allow multiple
applications (End Systems) to register to receive data on the same port. I
think there's a clarification of this later... [yes, in 3.2.5.2]
3.2.2 'four' primitives used by this service, followed by list of six things
:)
3.2.2.2 'T_BE_ReceiveData.request': '...is the list of Destination Service
Access Points (addresses, ports) that data...' '...The Address portions of
all Dest SAP entries must...'
Just after figure 3-1: '...blocks until the data packet has been accepted
for sending, or until the send operation fails.'
Just after figure 3-3: '...it will not be passed to the receiving process
and neither the sending nor the receiving application...'
Just after figure 3-4: 'TTL is a Time To Live counter, which is decremented
by 1 at each...'
Might want to say something about how QoS and TYPE are encoded in the
network PDU, maybe not.
3.2.5.1: 'A NULL value for a CB_Routine will cause the T_BE_SendData.request
to block, only returning once the buffer is freed or the timeout has
expired' Who frees this? Better not be the caller before the timer
expires. Suggest replace with 'returning only if the send completes or the
timer expires'
The return codes should probably also be returned by the SendData call in
the case that the caller passes NULL as the callback routine.
3.2.5.2: 'SAP_Type dest_SAP is the destination SAP (address and port number)
that the calling process wishes to receive data from'
BM__msocom_1
'length is the amount of data received and placed into the buffer' Probably
a cut-and-paste error. On calling you know the length of the buffer, but
you don't yet know how much data it will get.
Might want the dest SAP as a parameter to the callback routine as well. It
would just make it easier if I wanted to have a single high-level callback
routine to handle lots of different receive ports.
By putting data into only the first 'matching' buffer:
We preclude multipoint delivery that would be achievable if we allowed
multiple applications to register with the same destination port
We risk a rogue application registering to receive the data from some
other application. We have to allow multiple registrations on the same port
if we want to allow an application to register several buffers, so this may
be an issue.
in T_BE_ReceiveData_po: 'length is a value/return parameter. On input it
specifies the size of the buffer available to receive data. On return it
indicates the number of octets of data received.
A timeval of 0 (indicating return immediately) in the polling receive will
amlost never return with data, since there's no buffering in TCONS. Not
really a problem, just made me blink.
'...do not have a receive queue for applications.'
3.3.1 Suggest we say something about duplicate delivery such as: 'The
Prioritized, Guaranteed, Data Delivery service provides reliable, in-order
(within a priority), at-most-once delivery of data from one End System to
another.' (And if we can say 'application' instead of End System, so much
the better.)
If no acknowledgement is received...
The Guaranteed service can send units of data of an arbitrary size by
splitting them into a series of smaller packets of size less than or equal
to the MTU
Here we get into ordered delivery. Providing in-order delivery within each
priority class is going to be a real bear if there's only 'packet sequence'
counter for the entire (s,d) 'stream'. This would probably entail at least
one of:
1) guarantee that all packets (of all priorities) take the same path
2) link-layer retransmission with associated head-of-line blocking. This,
combined with the requirement to send high-priority packets first may mean
pulling a packet that's in the process of being retransmitted back out of
the data link layer in order to send a higher priority packet that just
arrived. This can be tough.
In the list of services: (The Guaranteed service has the following features)
Order preservation within each priority level is the only service that TCP
(with some combination of diffserv support from IP and urgent data) does NOT
offer (and TCP doesn't restrict segments to the MTU). urgent data only gets
you one 'high' priority, while TCONS has several, but still... Also, what
does 'Large data sent in segment' mean?
3.3.2.1
'If more than one application is registered then any incoming open requests
are [handled?] first based on Listens with both source...' Again the
difficulty of rogue apps, etc.
3.3.2.2 -- On open, my app has to specify the source SAP (address, port)? I
may not want to do that in my app, and there's the question about how to
deconflict, either among the same app or multiple ones at the same address.
If I have several applications that are all running on the same host, e.g.,
how do they coordinate so as not to use the same source SAP?
3.3.2.3 -- OK, this is one of the really grubby parts of absract service
definitions that I really don't like, but here it is. I believe that to
make this legitimate in the abstract service defn world, the
T_G_Open.Request() needs to pass in some sort of 'cookie' or token, and the
OpenConf.Indication returns the same token along with the connectionID.
It's the abstract service definition way of saying: "I call open() and it
returns me a connectionID"
As an example:
Semantics: Register.request shall provide parameters as follows:
Register.request( delivery failure action, registration token binding,
destination communications endpoint ID)
Semantics: RegistrationToken.indication shall provide paramers as follows:
RegistrationToken.indication ( registration token binding, registration
token)
3.3.2.6
In the T_G_SendConf.request (should be indication?) there's '...data has
been sent and received successfully at the intended destination.' What does
this really mean? That the data has been put into the application buffer at
the destination and the ReceiveData.Indication was given to the app?
There's a real danger here in that unless the destination application has
received, understood, and acted on the data, telling the source application
that it 'got there' may be misleading. Many people think that receipt of a
TCP acknowledgement for a piece of data means that the data got to the
receiving application. This is just not true.
After figure 3-5. '...criteria (destination SAP and source SAP)...'
Figure 3-6: Can you really have multiple connections on the same dest SAP?
Since data will be put (rather arbitrarily) into one or the other listener,
I'd think this might not be a good idea.
Figure 3-12: This is the first place that mentions sequence numbers.
Probably want to say something about them earlier. Also, do we need
sequence numbers on the open exchange (similar to syn/syn ack)? I still
need to check this.
After the numbered list: 'If the data arrives at the __destination__ but
has...'
3.3.3.3 I need to look up the 'why' for a 3-way close in TCP and figure out
if we should need something similar or not.
3.3.4.1 says that the sequence number is the sequence number of a _packet_.
Just to be clear, we're numbering packets, not bytes.
4.1 The Network layer is responsible for multiplexing various network
__datagrams__? across the underlying network?
QoS at the network level which includes
Is there a reason for using 'de-fragmentation' rather than 'reassembly'?
Reassembly's the more commonly-used term.
4.2.3 'Interrupt service __routine__ (not routing)'
4.2.5.2
The way I understand the network layer N_ReceiveReq() it's like registering
a particular transport protocol (like best effort vs. guaranteed)? If so
then we probably want to have the transport 'type' as a paramter here.
There's really no mention of how flow control is achieved. Nothing in the
Guaranteed Service PDU to support it (that I can see).
>-----Original Message-----
>From: sois-tcons-bounces at mailman.ccsds.org
>[ <mailto:sois-tcons-bounces at mailman.ccsds.org>
mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of Steve Parkes
>Sent: Monday, September 13, 2004 7:59 AM
>To: 'sois-tcons at mailman.ccsds.org'
>Subject: [Sois-tcons] TCONS Red Book Draft
>
>Dear TCONS Members,
>
>I'm sending this again because it appears to have got lost the
>first time!!
>
>Please find attached the latest version of the TCONS read book. Ignore
>sections 1, 2 and 5.
>
>Section 3 describes the Transport and Network layer protocols with the
>exception of the Scheduled Service (sorry I ran out of
>steam/time, but will
>complete this section before the next SOIS meeting).
>
>Section 4 describes the sub-network dependent convergence layer (to be
>renamed Generic Data-Link Layer).
>
>Please do not edit the document. Please do send me comments. I
>will do the
>editing.
>
>Max, Keith, Dai please check the abstract primitive
>definitions to make sure
>I have written about them in the right way.
>
>Greg, Keith, Stuart (Mills) please check the APIs to make sure
>they are real
>C-code and make sense.
>
>Rick please check the sub-network convergence layer since this
>is really an
>OBL task (I think).
>
>Max is there enough information to start the SDL modelling, if
>so can you
>get it done before the next SOIS meeting?
>
>Jane please check the overall consistency of the document
>(sections 3 and 4
>only).
>
>Thanks
>
>Steve
>
>
>
>---------------------------------------------
>Steve Parkes
>Space Systems Research Group
>Applied Computing
>University of Dundee
>Dundee, DD1 4HN
>Scotland, UK
>Tel: +44 1382 345194
>Fax: +44 1382 348838
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20041007/c000c883/attachment-0001.htm