[Sois-tcons] Telecon this Friday

[Jane K. Marquart]

At 05:12 PM 6/1/2005 -0700, Abhijit Sengupta wrote:
>At 6/1/2005 09:55 AM, Jane K. Marquart wrote:
>>Dear TCONS/OBL members,
>>
>>We'd like to have a telecon this Friday at 11:30 EST to discuss plans for 
>>getting out the books.  I've included the following from Steve to get us 
>>thinking about it before the telecon.
>>
>> >The key issues are how we define the QoS and where we split the stack for
>> >the red books. There are currently two views on this, both of which I agree
>> >with (something about training as a physicist and getting to grips with
>> >particle/wave duality):
>
>Please recall how the QoS specification comes from TCOAS - basically, 
>defining bounds on different service parameters like delivery time or 
>jitter, bandwidth etc. Your definition of QoS needs to be something that 
>can readily be mapped from specification from TCOAS.
>> >1. Split TCONS/OBL at the bottom of TCP/IP and above the sub-network level
>> >where the QoS is done. This is the view that Rick put forward. In this case
>> >OBL offers a set of services which provide different QoS to TCP/IP and
>>TCOAS
>> >(and possible TCONS protocols).

Can you send us the TCOAS QoS spec referenced in your next comment?  It 
would help to ensure that TCONs is compatible.

>> >2. Split TCONS/OBL below the sub-network level so that the QoS services are
>> >generic to all the underlying buses. This is the view that Dai put forward.
>> >It preserves the role of TCONS looking at the QoS issues (in line with the
>> >charters) but is disadvantageous if all the QoS if handled differently by
>> >the various buses.
>
>In either case then, transport or network layer functionalities do not 
>care about QoS specification which might be a serious problem. Please 
>recall that QoS specification from TCOAS is not concerned with whether the 
>source and destination applications are on same subnetwork or not - in 
>fact the applications do not have a clue (in general) where the recipient 
>application is running.

It is true that the apps shouldn't be concerned with where the recipient 
is.  However, for this go-round, we have determined that time-critical 
services are only provided on a single sub-network.  So depending on what 
type of service is requested, QoS options vary.


>Abhijit
>
>________________________________________________
>All personal and professional opinions in this email are my own
>and do not represent, in any way, the opinion or policy of JPL
>________________________________________________

Jane