Subject: RE: stateless proxy...

From: Sean Olson <[email-masked]>
Date: Thu, 19 Aug 1999 21:32:18 -0500 (CDT)

> 
> I would say this: if a proxy server is stateless, all that means is that it
> doesn't maintain transaction state.  It can still perform "call state"
> functions, like executing CPL scripts or enhanced features, even if it can't
> perform transaction state management.
> 

Performing "call state" functions on a stateless proxy begs the question
why is the proxy stateless in the first place? (I would also argue that
performing such functions on a stateless proxy would be next to impossible)

> Therefore, if it gets the Proxy-Requires but doesn't support the extension
> (a proprietary CPL ID, for example), I'd say it should generate the 420.
> 
> Does the group agree?  If so, the RFC should be modified, like Vipul
> suggests.
> 

This seems reasonable for 4xx or 5xx responses. If the response gets lost
(UDP), the UAC will re-send the request which will again be responded to 
with a 420. When the UAC ACKs the response, the stateless proxy can
silently discard the ACK. 

> Cheers,
> Alex
> [email-masked]
> 
>     -----Original Message-----
> 
>     In section 10.2.1 of RFC 2543 it says following:
>             Recall that responses are not generated by the next-hop
>             stateless server, but generated by either a proxy server or
>             the user agent server. Thus, the stateless proxy can only
>             use the Via header field to forward the response.
> 

I believe this paragraph is just to clarify why the Via: headers must be
used for proxying a response (since a stateless proxy keeps no state for
the transaction). I don't believe (please correct me if I'm wrong) that this
was intended to mean that stateless proxies MUST not generate responses 
(except for the obvious 2xx, 6xx responses).

>     What should a stateless proxy server do when it receives a Request
>     containing  Proxy-Require  header field with option(s) it does not
>     support.
> 
>     Which of the following it should do:
> 
>     (1)  Generate 420 BAD EXTENSION response.
>             (Since, it cannot generate Responses, it is not correct)
> 
>     (2) Ignore the Proxy-Require header field and forward the Request
>             to the next hop.
> 
>     (3) Ignore the Request and drop it
> 
>     (4) None of the above... then WHAT.
> 
>     Thanks,
>     Vipul.
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:[email-masked]
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com
> 

regards
-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 20 Aug 1999 01:23:51 -0400

> silently discard the ACK.

No, this it should not do. The notion of stateless and stateful proxies
is a logical distinction. Real servers probably include proxies
(stateless, stateful, and call-stateful), registrars, and redirect
servers. Thus, its perfectly reasonable for a normally stateless proxy
to send an error response (in which case its not stateless for this
transaction). Once it sends a response, it should be prepared to handle
the ACK. 

Its also probably OK to forward the request statelessly like any other,
but I wouldn't recommend this. The Proxy-Require header may specify a
feature which would make normal stateless proxy behavior incorrect. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Aug 1999 12:46:20 +0300

Hi,

Jonathan writes:

> Thus, its perfectly reasonable for a normally stateless proxy

What do we gain by doing this? If we store state for this transaction
and we receive again the request, we will have cached the response and
we will save a bunch of hundreds of miliseconds... then, when the ACK
arrives, we will destroy our state, but we do not need to handle
furtherly the ACK (do we? )...

If we do as Sean proposes, if the request arrives again, we'll lose some
time building the response, and when we discard silently the ACK we
don't lose anything. On the other hand, we gain that we do not need to
store any kind of state for the call...

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 20 Aug 1999 10:33:37 -0500 (CDT)

>transaction). Once it sends a response, it should be prepared to handle

"Handle" the ACK in what capacity? The ACK generally serves the
purpose of saying "Okay; I got the response. You can stop
(re)transmitting it now." Your answer implicitly says that
stateless proxies *must* be prepared to re-transmit 420 replies.

If you say that:

1) A stateless proxy must respond with a 420 to any Proxy-Require
   headers it does not understand and,

2) Stateless proxies must "handle" ACKs (e.g. retransmit replies),

...then stateless proxies need to maintain session state (keep
correlation around for a certain length of time, keep timers
for retransmissions, correlate responses, etc).

Which is *exactly* what stateless proxies Do Not Do. That's what
makes them stateless. A stateless proxy that keeps state is
not a stateless proxy.

The solution Sean proposes seems to fit in neatly with the 
rest of a stateless proxy's operation. You seem to have an
objection to it, but your response doesn't provide much
rationale.

Directly: what is broken about depending on the UAC retransmission
to trigger a new response instead of keeping local timers?

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA