Re: IRIP version 4 (Part 1) - ICALDATA

[Doug Royer <Doug.Royer@xxxxxxx>]

> From: Bruce_Kahn@iris.com
> Date: Sun, 21 Mar 1999 19:50:20 GMT
> 
> Doug replied (in part):
> >> Is this intended to allow a CUA to attach to the CS over iRIP and
> >> "retrieve" a calendar entry?
> >
> >Retrieve a reply that was delayed.
> 
> Please clarify this in the text then.

Too much was cut - I am not sure of the context :-)

> >... Unless I miss your point, 'ICALDATA:<timeout>' ?
> >If its the same timeout that goes with ICALDATA, no - they would
> >not be compliant.
> 
> (Further down in the draft is the info I didnt see on first pass about time
> limits but...)  So, a sender has the option to be a 'hog' and the receiver
> must obey that?!?  (ie: ICALDATA:100000)  I sure hope that you just misread
> my question.  The receiver's admin MUST have the ability to set and enforce
> their own limits that take prescedence over those of the sender.  Otherwise
> I could cripple any CS by simply doing some operation that eats ALL of the
> resources and lets no one else do anything...  Bad design!

Did you have a proposal?

Is there an example of any protocol that you could give as an
example that solved this problem?

As to the cripple issue, I don't know of any protocol that can
fight a malicious client.

> >I don't understand the above question.
> 
> Ok, the sender indicates the RECIPIENTs and then does an ICALDATA.  The
> receiver does NOT complete the work in the time specified.  The sender must
> either issue a CONTINUE or an ABORT.  It would make the senders decision
> easier if it could be told "Completed 7 of 10 RECIPIENTs", etc.  That way
> it can tell if the receiver is making any progress.  For example, the next
> time into the Idle state returns "Completed 7 of 10 RECIPIENTs" would
> indicate either a problem w/#8 and that the sender may want to ABORT
> instead of CONTINUE again.

What if the CS does not know there are '8'.  Example, tell me prior to
doing a query, how many 'would' return if it were not going to hang?
The CUA can always issue an ABORT at any time.  We had already
discussed the fact that the CS may never return (powered down for
example) and the the CUA must be able to deal with that.

Yes - the CS admin and the CS implementation could have limits.
That's not a protocol issue. Is it?

> A more complex train of thought would be for the receiver to indicate (on
> entering Idle) which addresses it completed and which it didnt (or to
> return them w/o waiting for the rest of the data to be bundled up).  Since
> we talked about tagging and returning data as it is ready and not bundling
> it all (in Minneapolis) this may be a moot issue.

It already has ONE status reply for EACH reciepient. I think
that's the same thing.

> Just be sure you address how the receiver should behave when it is sending
> data back and the ICALDATA timer expires (ie: there is lots of data to be
> sent and it is still being sent after the 10 second timer expires).
> Should the reciever quit sending data back or should it keep streaming it
> to the sender until its done?  When this case happens, when should the
> senders CONTINUE 15 begin; the time it is received or after the last data
> has been sent??  (Multithreaded CSs make this an issue you need to
> address!)

I think it has already been addressed.  I read the timer as "If you
can't get back to me in XX seconds...".  If the CUA is getting data,
then the CS got back to the CUA - correct?

> >> Is there any way for the sender to find out which RECIPIENTs were
> completed
> >> and which were not??  For example, I send to 10 RECIPIENTs but for some
> >> reason the server can only complete 6 of them.  It would be really
> really
> >> nice to know who completed successfully and who didnt so I dont have to
> >> redo the entire operation and double book something (or so I could
> DEQUEUE
> >> the entry from those successful ones until it works for all 10!!!)
> >
> >There is a response for each RECIPIENT.
> 
> True but its only sent on the response.  (Prior to Minneapolis) the
> response data was bundled so the sender could not see this UNTIL the work
> was done or ABORTed.  After the fact is not helpful in deciding whether or
> not to CONTINUE...  I look forward to seeing the revised draft on reponse
> tagging of streamed data that clears this up.

ok.

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL