Subject: Q: NoSuccessAck and Window Size

From: "Georg Kullgren" <[email-masked]>
Date: Thu, 21 Jun 2001 10:28:07 +0200

Hi,

I'm implementing GSMPv3 and needs some help from the expertise on this list.
My problem concerns NoSuccessAck (RFC1987) and Window Size (RFC2297).

When the controller sends a request, the transaction ID has to be saved
in order to check the validity of the response.
Even though nothing is said in the draft I assume that a reply will
be ignored if the transaction ID doesn't match any outstanding requests.

The Window Size will limit the number of outstanding requests.

If I send a lot of requests with NoSuccessAck, they will fill up the
Window.

And now to my question:
For how long should a request with NoSuccessAck be considered to
be an outstanding request if no reply is received?

A too long time-out will fill up the window.
A too short time-out will cause a failure response to be ignored
since the original request isn't outstanding anymore.

IMHO I think we would be better off without NoSuccessAck.

Regards
/Georg

-- 
------------------------------------------------------------------------
Georg Kullgren            Nortel Networks AB    [email-masked]
System Architect          S:t Eriksgatan 115 A  Tel:   +46-8-50 88 36 18
Routing Architecture Lab  SE-113 85 Stockholm   Mobile: +46-703-14 36 18
                          Sweden                Fax:   +46-8-50 88 35 01

---

From: "tom worster" <[email-masked]>
Date: Fri, 22 Jun 2001 09:00:21 -0400

From: Georg Kullgren
> be ignored if the transaction ID doesn't match any 

i think the controller may choose what it does in this
case.

> IMHO I think we would be better off without NoSuccessAck.

NoSuccessAck has been used a lot in the past so it
might be better to find another way to resolve the
confusion.

it doesn't make sense for a controller to wait for a 
response when it hasn't asked for one. if a controller
needs to buffer a request in case of a failure response 
then, as a matter of good housekeeping, it should not 
use NoSuccessAck in the request.

so perhaps we ought to say in the text that requests
with NoSuccessAck do not count towards window.

c u
fsb

---

From: "Georg Kullgren" <[email-masked]>
Date: Mon, 25 Jun 2001 09:04:15 +0200

> i think the controller may choose what it does in this

OK.
So I can choose to accept all incoming replies and basically ignore
the transaction ID.

> with NoSuccessAck do not count towards window.

The Window Size is used to prevent an overflow in the receivers
input buffer. To exclude some messages from the window will break 
this and can cause a buffer overflow.

I agree that it doesn't make sense to wait for answers when using
NoSuccessAck. The problem is how long do I need to count a
NoSuccessAck against the window before I can be sure that the
receivers input buffer won't overflow?

This is not a problem when when using TCP encapsulation, but other
encapsulations don't have an internal flow control.

Regards
/Georg

---

From: "tom worster" <[email-masked]>
Date: Tue, 26 Jun 2001 08:30:19 -0400

From: Georg Kullgren
> So I can choose to accept all incoming replies and basically ignore

yes. although i don't think that would be a good 
strategy if the controller cared about reliability.

> this and can cause a buffer overflow.

yes. however, if the buffer overflows and an AckAll
request is lost, the controller has a procedure to
notice and resend. it doesn't matter if the 
NoSuccessAck requests are lost in a buffer overflow, 
the controller doesn't care about those anyway.

> receivers input buffer won't overflow?

if a controller thinks that it is important to 
not overflow the switch's rx buffer then it should 
either not send NoSuccessAck requests or, perhaps
less reasonably, be conservative and count them 
against the window for what it considers a long 
time.

note that in general gsmp leaves a lot of 
flexibility in the design and implementation of 
controllers and much less for switches. the above 
discussion is one example of that.

> encapsulations don't have an internal flow control.

you are assuming a sensible switch implementation in 
which the gsmp message processing queue is coupled to 
the tcp flow control, i.e. the a transport ack counts
as an application layer ack. that may be a good 
assumption but one might want to check.

c u
fsb