Subject: [AAA-WG]: Issue 72: Downstream/upstream confusion

From: Pat Calhoun <[email-masked]>
Date: Tue, 12 Jun 2001 06:57:28 -0700

Jacques,

I've looked at the base protocol, and I cannot find any inconsistencies in the use of
the terms downstream and upstream. In all cases, upstream implies towards the home 
server, and downstream is towards the access device.

I have asked the list of folks think this needs to be changed, and there doesn't appear
to be any consensus, so I am against changing it at this point.

To me, something goes up before it goes down, so it seems logical to me that a request
go up towards the home, and back down towards the access device. The only way this logic
is broken is for unsolicited server-initiated messages, when things go down before they
go up :(

so looking at your proposed fixes. you seem to request that the terms be inversed,
but your issue description implies that the terms are used inconsistently. Could
you point to these areas, since a read through the document doesn't help me find 
them :(

Thanks,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Tue, 12 Jun 2001 20:23:54 +0200

Pat,

Not sure I agree with the definition of up/downstream. For me the fact that 
we define that as "upstream" and "downstream" rather than "up" or "down" is 
a reference to a flow (like a river). And such flow normally goes from 
upstream to downstream (the terms are used in reference to the direction of 
"normal" requests).

But the important thing is that everything is consistent. If you don't want 
to change the definitions for up/downstream, change the following:

In 6.1 Application Identifiers:

    Diameter relay and proxy agents are responsible for finding a
    downstream server that supports the application of a particular
    message. If none can be found, a MRA message is returned with the
    Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

Should be upstream, then.

And in 10.10  Inferring Session Termination from Origin-State-Id:

    When a Diameter server receives a Origin-State-Id that is greater
    than the Origin-State-Id previously received from the same issuer, it
    may assume that the issuer has lost state since the previous message
    and that all sessions that were active under the lower Origin-State-
    Id have been terminated. The Diameter server MAY clean up all session
    state associated with such lost sessions, and MAY also issues STRs
    for all such lost sessions that were authorized on downstream
    servers, to allow session state to be cleaned up globally.

Should be upstream too, then.

Jacques.

>you point to these areas, since a read through the document doesn't help 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 13 Jun 2001 07:20:12 -0700

> upstream to downstream (the terms are used in reference to the direction of 

We appear to be saying the same thing. Things do upstream, and then downstream.

> 
> But the important thing is that everything is consistent.

agreed.

>  If you don't want 

correct.
> Should be upstream too, then.

hmmmm.... this text comes from Paul, and I missed the problem here. First of
all, this text implies that the server initiates an STR, when this is typically
done by the access device. So, perhaps ASR is what was meant here. In which 
case downstream would be correct, but not "downstream servers", and instead
"downstream clients".

Paul?!?

PatC

---

From: Jacques Caron <[email-masked]>
Date: Wed, 13 Jun 2001 17:50:26 +0200

>We appear to be saying the same thing. Things do upstream, and then 

Nope. I say things go FROM upstream TO downstream. In our case, upstream 
and downstream define relative locations, not directions :-)

>case downstream would be correct, but not "downstream servers", and instead

Well, since the server (or rather proxy in this case) just detected that 
the client rebooted, there is no need to terminate all sessions on the 
client... I think it's another issue of those famous STRs sent by proxies 
"on behalf" of the NASes erk erk erk ;-)

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 13 Jun 2001 09:23:38 -0700

> and downstream define relative locations, not directions :-)

Ah, now I get your point. It depends upon where the message was originated, and the
request is always upstream, and the answer is always downstream. Is this correct?

> "on behalf" of the NASes erk erk erk ;-)

That is some nastiness that the protocol shouldn't support, IMHO. Adding this
complexity to proxies is really unnecessary, since the NAS would have to know
anyways whether it should send an STR, and you may end up in a situation where
both the NAS and a proxy send STRs.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Wed, 13 Jun 2001 18:37:48 +0200

>request is always upstream, and the answer is always downstream. Is this 

The request follows the stream, and goes from upstream to downstream. The 
answer is a bit weird since it goes downstream to upstream (like a salmon 
that tries to go upstream to lay its eggs...)

>both the NAS and a proxy send STRs.

If the NAS rebooted, it does not know anything about the previous 
sessions... The goal of the previous paragraph is to do some quick cleanup, 
i.e. be a bit more proactive on fixing the sessions that got lost than 
having the server wait for the next request from that client (which might 
be very far away in the future in a roaming environment).

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 13 Jun 2001 09:31:13 -0700

> that tries to go upstream to lay its eggs...)

hmmmm..... ok. I don't actually mind this since the text in the draft currently
assumes that the message is from the access device towards the home, and this
isn't true for server initiated messages. Therefore, I would be willing to make
such a change, if the WG agreed.

> be very far away in the future in a roaming environment).

duh. sorry, I had forgotten that's what this was used for :(

PatC