Subject: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Aug 2006 22:15:19 +0200

Hi all,

we discussed this document during the IETF#66 DIME working group 
meeting. The meeting participants did not express excitement. We would 
like to solicit feedback from the working group to see whether there is 
interest in this work and how we should proceed.

Ciao
Hannes & John

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 16 Aug 2006 17:18:48 -0400

I think the mechanism described in this draft could be useful for certain
cases. My understanding is, depending on the scenario, there may be other
solutions as well and at the end it is the operators choice to deploy this
or that alternative.

What needs to be done about this draft is also very much dependent on the
famous AppId discussion about the common messages defined in the base
protocol. To me, using AppId=0 for such messages is clearly a bug in the
base protocol and needs to be corrected, because it breaks the routability
of the messages for some very-real configurations. OTOH, I am also
acknowledging the backward compatibility issue. So, depending on the
decision of WG, I personally prefer the following:

A) WG wants to keep AppId=0 for base protocol common messages
- Add a section to 3588-bis about the routing problem and possible
solutions. I would prefer some not-so-shallow discussion of the issue in the
document with explanation of what type of topologies would work and which
ones won't.
- draft-tsou-dime-base-routing-ext-00 becomes a WG document
- We either update draft-tsou-dime-base-routing-ext-00 to reflect other
possible solutions to the problems it addresses or discuss all of them in
another draft.

B) WG decides to use AppId!=0 for base protocol common messages
- Work on draft-tsou-dime-base-routing-ext-00 continues with discussions on
the mailing list, it gets updated if necessary and possibly becomes a WG
item. I lean to think, it should be a WG-item.
- We either update draft-tsou-dime-base-routing-ext-00 to reflect other
possible solutions to the problems it addresses or discuss all of them in
another draft.

My choice would be B).

    Thanks,
    Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2006 4:15 PM
> To: Tina TSOU; Victor Fajardo
> Cc: [email-masked]
> Subject: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> Hi all,
>

---

From: Tony Zhang <[email-masked]>
Date: Thu, 17 Aug 2006 14:13:08 +0800

My Choice is :
(1)use AppId!=0 for base protocol common messages
(2) draft-tsou-dime-base-routing-ext-00 should be a WG_ITEM

Regards!
Tony

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 5:19 AM
To: Hannes Tschofenig; Tina TSOU; Victor Fajardo
Cc: [email-masked]
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

My choice would be B).

    Thanks,
    Tolga

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 17 Aug 2006 11:47:37 -0400

I think the content of draft-tsou-dime-base-routing-ext-00 should be
integrated into rfc3588bis, because I think source routing is needed
to support stateful agents and thus should be part of base protocol.

Also, I think that source routing issue can/should be discussed
separately from the Application Identifier issue.

Yoshihiro Ohba

---

From: Tina TSOU <[email-masked]>
Date: Fri, 18 Aug 2006 09:31:24 +0800

I agree with Yoshihiro.

B. R.
Tina

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 18 Aug 2006 12:15:53 -0400

Hi Yoshihiro,

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Thursday, August 17, 2006 11:48 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
[TOLGA]I think we should distinguish between intermediaries, which advertise
support for individual applications instead of 0xffffffff but are not really
stateful and which are really stateful. Currently being stateful and
advertising specific application support is tied together in RFC3588 by
definition of a proxy but I don't think it needs to be. Acctually not doing
so is not violation of the protocol, just defining a new node type, which is
not explicitly mentioned in RFC3588.

An example for the first one is a load-balancer for a specific application.
It is interested to get only messages for a specific application but doesn't
keep session related state. If a message does not have Destination-Host AVP,
it forwards the message to a server based on congestion status of servers
(how this information is propogated is topic for another thread). If a
message has Destination-Host AVP, it just sends the message to that server.

For that first type of intermediaries, everything would be working fine if
AppId!=0 is used for common messages. Otherwise, a relay agent in front of
load balancers serving different applications is enough to have common
messages not routable to the correct load balancer.

For second type of nodes, which are stateful and want to stay on the message
path, a mechanism as described in the draft is usefull. There could be other
solutions as well -which we discussed to some extent on the list-, and I
would prefer them to be explained -somewhere-.

> separately from the Application Identifier issue.
[TOLGA]I see some correlation because using AppId=0 for common messages
breaks routability of such messages for some configurations and the draft
provides a solution for that. Otherwise, the draft is useful only for
intermediares, which want to stay on the path during a session.

---

From: <[email-masked]>
Date: Mon, 21 Aug 2006 08:50:08 +0300

Hi all,

A very basic question - do we have consensus that we need source
routing and that it is a basic functionality?  Is this something
that is broken in the current document.  If so, then it should
be fixed in the base.  If this is an additional feature, then
it might be fine to have this as an extension draft.

thanks,
John

>From: ext Tolga Asveren [mailto:[email-masked]] 
>Sent: 18 August, 2006 19:16
>To: Yoshihiro Ohba
>Cc: [email-masked]
>[TOLGA]I think we should distinguish between intermediaries, 
>which advertise support for individual applications instead of 
>0xffffffff but are not really stateful and which are really 
>stateful. Currently being stateful and advertising specific 
>application support is tied together in RFC3588 by definition 
>of a proxy but I don't think it needs to be. Acctually not 
>doing so is not violation of the protocol, just defining a new 
>node type, which is not explicitly mentioned in RFC3588.
>
>It is interested to get only messages for a specific 
>application but doesn't keep session related state. If a 
>message does not have Destination-Host AVP, it forwards the 
>message to a server based on congestion status of servers (how 
>this information is propogated is topic for another thread). 
>If a message has Destination-Host AVP, it just sends the 
>message to that server.
>
>For that first type of intermediaries, everything would be 
>working fine if AppId!=0 is used for common messages. 
>Otherwise, a relay agent in front of load balancers serving 
>different applications is enough to have common messages not 
>routable to the correct load balancer.
>
>For second type of nodes, which are stateful and want to stay 
>on the message path, a mechanism as described in the draft is 
>usefull. There could be other solutions as well -which we 
>discussed to some extent on the list-, and I would prefer them 
>to be explained -somewhere-.
>
>>
>[TOLGA]I see some correlation because using AppId=0 for common 
>messages breaks routability of such messages for some 
>configurations and the draft provides a solution for that. 
>Otherwise, the draft is useful only for intermediares, which 
>want to stay on the path during a session.
>>
>> Yoshihiro Ohba
>>
>>
>> > meeting. The meeting participants did not express excitement. We 
>> > would like to solicit feedback from the working group to 
>see whether 
>> > there is interest in this work and how we should proceed.
>> >
>> > Ciao
>> > Hannes & John
>> >

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 21 Aug 2006 11:37:16 +0200

Hi John, 
Hi all,

John raised a good point. 

I went through the mail discussions trigger by
http://www1.ietf.org/mail-archive/web/dime/current/msg00212.html

A draft with a solution was submitted
http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-00.txt

Most discussions focused on details of solutions. I was not able to find 
a good problem description, requirements or scenarios. It is not even 
clear whether there is a real world problem here.

Who is going to write a problem statement/requirements document? 

Ciao
Hannes 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Montag, 21. August 2006 07:50
> An: [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> 
> Hi all,
>

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 21 Aug 2006 10:29:02 -0400

Hi John,

> that is broken in the current document.  

The intention of the document was to propose an "extension" to the 
current routing functionality of the base to fulfill requirements in 
topologies where this functionality is needed. (i think these 
topologies/scenarios has been discussed lengthly in the list). Following 
your guideline, I think it maybe better that this should be an extension 
document given that it is not proposing changes to the existing routing 
schemes. I also think that the WG should work on this document since it 
does fulfill real world requirements.

regards,
victor

> If so, then it should
>>> Subject: Re: [Dime] Next Steps for 
>>>       
>> draft-tsou-dime-base-routing-ext-00
>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 21 Aug 2006 10:48:46 -0400

Hi Tolga,

> not explicitly mentioned in RFC3588.

What description in RFC 3588 ties being stateful and advertising
specific application support by definition of a proxy?

In fact, statefulness is not a requirement for a proxy.

So I don't understand what problem is solved with defining a new node
type.

> messages not routable to the correct load balancer.

This first case does not require a stateful agent, so I agree with you
that it may not be appropriate to discuss
draft-tsou-dime-base-routing-ext-00 to address the first case.

> would prefer them to be explained -somewhere-.

Source routing is needed at least to support stateful agents that is
defined in RFC 3588 but actually is not completely supported by RFC
3588.  For completeness of the base specification, I'd suggest
defining source routing in the document that defines stateful agent,
but I am also ok with defining it in a separate document if the
document is referred from RFC3588bis.

> intermediares, which want to stay on the path during a session.

I'd think that the draft is useful only for stateful agents.

Regards,
Yoshihiro Ohba

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 21 Aug 2006 12:28:01 -0400

Hi Hannes,
> Hi Victor, 
>
> in the discussions the 3GPP WLAN work was mentioned as the usage scenario. 
> Is it a real problem in their environment? I have never heard something about problems along these lines. 
>   

 From what I understood, it is a problem envisioned by some folks when 
trying to deploy diameter in such environment. I think Tina and others 
can shed light into this better than I can.

regards,
victor

>> Von: Victor Fajardo [mailto:[email-masked]] 
>> Gesendet: Montag, 21. August 2006 16:29
>> An: [email-masked]
>> Cc: [email-masked]
>> Betreff: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>>
>> Hi John,
>>
>>     
>>> Hi all,
>>>
>>>> Subject: RE: [Dime] Next Steps for 
>>>>         
>>>>> I think the content of 
>> draft-tsou-dime-base-routing-ext-00 should be 
>>     
>>>>> integrated into rfc3588bis, because I think source 
>>>>>           
>> routing is needed 
>>     
>>>>> to support stateful agents and thus should be part of 
>>>>>           
>> base protocol.
>>     
>>>>>       
>>>>>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 21 Aug 2006 18:21:22 +0200

Hi Victor, 

Ciao
Hannes

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 21 Aug 2006 17:34:25 -0400

Hi Yoshihiro,

> Sent: Monday, August 21, 2006 10:49 AM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; [email-masked]
> which advertise
[TOLGA]I didn't propose to define something new but it is my bad to assume
proxies are by definition stateful.
> application but doesn't
> working fine if
> on the message
[TOLGA]IMHO, source routing is only one of the possible solutions to this
problem, which may be more attractive than the other ones for certain
configurations. Overall, I also think that it should be a WG-item.
> I'd think that the draft is useful only for stateful agents.
[TOLGA]AFAICS, your statement is true only if AppId!=0 is used for common
messages. Consider the following scenario, where all intermediaries are
stateless:

                    +---------+
                    |Load     +------- Servers
                +---+Balancer +------- for App1
 +-------+      |   |for App1 +-------
 | Relay +------+   +---------+
 | Agent +------+
 +-------+      |   +---------+
                |   |Load     +------- Servers
                +---+Balancer +------- for App2
                    |for App2 +-------
                    +---------+

Load balancers are stateless but advertise support for only App1 and App2
respectively. The first message of a session will have the AppId for either
App1 or App2 and so could be routed to the correct load balancer. OTOH, and
mid-session common message would have App-Id=0, and relay agent won't have
enough information to select the right load balancer, unless it knows the
identities of each server and which load balancer can be used to reach that
server (If that were true, it could route by making use of Destination-Host
AVP). Requring such a configuration is quite a restriction. The mechanism in
the draft would allow the load balancers to insert themselves in the session
path. This IMHO is not an ideal solution for this problem, but if we are
stuck with AppId=0 for common messages, it is better than nothing.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Aug 2006 08:03:44 -0400

Hi Tolga,

In your example below, all messages (i.e., the first and subsequent
messages) for a session need to be routed to the same server where a
server is chosen by a load balancer when routing the first message.
In this case I think hop-by-hop routing based on Destination-Host AVP
is sufficient and source routing is not needed.

Yoshihiro Ohba

On Mon, Aug 21, 2006 at 05:34:25PM -0400, Tolga Asveren wrote:

(snip)

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 22 Aug 2006 08:00:30 -0400

Hi Yoshihiro,

> Sent: Tuesday, August 22, 2006 8:04 AM
> To: Tolga Asveren
[TOLGA]The problem is not between load balancers and the servers, it is
between relay agent and the load balancers. AFAICS, if the relay agent is
unaware of the identities of the servers and their mapping to different load
balancers, it can't route mid-session common messages to the correct load
balancer efficiently.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Aug 2006 11:21:59 -0400

Hi Tolga,

Relay agent is aware of the server's identitity based on
Destination-Host AVP which is supposed to exist in all mid-session
common messages.  Am I missing something?

Yoshihiro Ohba

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 22 Aug 2006 11:07:46 -0400

Hi Yoshihiro,

Yes, you are right that Relay Agent can access Destination-Host AVP in the
message. OTOH, unless it knows which load balancer needs to be used to reach
a specific server, there will be a problem with routing for mid-session
common messages (which wouldn't be a problem if common messages used
AppId!=0, because then we could have relied on AppId in the message header
for routing). IMHO, requiring relay agents to configure that type of
information is a big and non-elegant restriction.

    Thanks,
    Tolga

> Sent: Tuesday, August 22, 2006 11:22 AM
> To: Tolga Asveren

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Aug 2006 11:56:50 -0400

Hi Tolga,

OK, now I clearly understand your scenario.

Thank you,
Yoshihiro Ohba