Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Fri, 26 September 2014 06:57 UTC

Return-Path: <ulrich.wiehe@nsn.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085E21A1A6B for <dime@ietfa.amsl.com>; Thu, 25 Sep 2014 23:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WviYWeNxOiI5 for <dime@ietfa.amsl.com>; Thu, 25 Sep 2014 23:57:36 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803751A1A5A for <dime@ietf.org>; Thu, 25 Sep 2014 23:57:33 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8Q6vUKp013508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Sep 2014 06:57:30 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8Q6vTbf007617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 08:57:29 +0200
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 08:57:29 +0200
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 08:57:29 +0200
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4CAALBYAIAA2puggABHyYCAAVSmwIAFD/sAgA/fwpCAAPDc0A==
Date: Fri, 26 Sep 2014 06:57:28 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520B6A4@DEMUMBX014.nsn-intra.net>
References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <E194C2E18676714DACA9C3A2516265D2026C2A8B@FR712WXCHMBA12.zeu.alcatel-lucent.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <B1FB443E-36D4-4A51-AF4B-C71A65A236F1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <EAD03A39-440B-4E38-B56B-241A8D17EA3B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> <54170666.3050900@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BCEB@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920983BCEB@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.109]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 19573
X-purgate-ID: 151667::1411714650-0000437E-0B8DC24D/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lCe7ByvGlXBom1o8NJYHg0TZjIs
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 06:57:42 -0000

Dear Maria Cruz,

thank you for your support.

With regard to issue 2 I was thinking of e.g.the following configuration:


+---+                                          +---+
|   |------------------------------------------|   |
| C |            +---+                         | S | 
|   |------------| A |-------------------------|   |
+---+            +---+                         +---+  |
 
C supports loss
A supports loss and rate
S supports loss and rate

1. for a host routed request from C to S (that possibly does not transit A (and if so, A would be transparent with regard to OC-AVPs)), S would send a host type OLR for loss to C.
2. for a realm routed request sent from C to A where A then selects S, S would send a host type OLR of rate to A and A would send a realm type OLR of loss to C.

I hope this is not contentious so far.

The open question is whether the answer send from A to C which contains the realm type OLR of loss must also contain a host type OLR. It seems clear that A cannot just transparently forward the received host type OLR of rate to C as C does not support rate. It has then been proposed that A would somehow calculate a host type OLR of loss on behalf of S and insert it into the anser sent from A to C. 
This means that C in step 1 receives a host type OLR of loss from S and in step 2 C receives a host type OLR of loss from S (actually from A on behalf of S, but C cannot know), and these two OLRs cannot easily be in sync.   

Best regards
Ulrich



-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] 
Sent: Thursday, September 25, 2014 6:02 PM
To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Dear Ulrich, Steve, JJ,

I think Ulrich summarized this discussion very clearly and even proposed a way forward as a compromise. I agree with his argumentations and with the proposal.

I only do not understand issue 2 (Host type OLRs received by the client may easily get out of synch), I would appreciate some clarification.

But I think we need to focus on issues 3 and 4:
>> 3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-type request.
>> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used.

Steve, you mentioned your proposal focusses on 3 and 4, could you explain it further?
Best regards
/MCruz




-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 15 de septiembre de 2014 17:32
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example

Ulrich,

A few more comments inline.

Steve

On 9/12/14, 4:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> please see inline.
>
> Ulrich
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Thursday, September 11, 2014 3:54 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
>
> All,
>
> It seems the concern is forcing the client to save OCS state for host
> reports from servers to which the client never sends host routed
> requests.  This, I think, is only an issue for requests that do not
> contain a destination-host AVP.  Please correct me if I'm mistaken.
>
> <Ulrich>
> I listed 4 issues (see below). You address only half of issue 4.
> The other half is forcing the client to save OCS state for realm reports
> from agents (realms) to which the client never sends realm routed requests.
> </Ulrich>
>
> I think we all agree that the server has no way to differentiate host
> routed requests from realm routed requests in this case, so the solution
> cannot be server based.
>
> That leaves two options:
>
> 1) The agent that does the server selection strips the host report for
> these types of transactions.
>
> 2) The client ignores host reports for these types of transactions.
>
> <Ulrich>
> I agree that these are the options when the request was realm-routed.
> When the request was host routed the options are
>
> 1') The agent does not insert a realm report to an answer forwarded
> from server to client
>
> 2') The agent inserts a realm report and the client ignores it.
SRD> There are scenarios where realm reports cannot be used. 
Partitioning of the server space is the primary example.  As such, we 
need to make sure we aren't designing a solution that depends on realm 
reports.  That's not saying that realm reports don't have value, just 
that they can't always be used.
>
> At least we should allow option 1 (and 1'); or are there any issues
> with this option? Whether or not to allow option 2 (and 2') needs to be
> discussed, as there are issues.
> </Ulrich>
SRD> I disagree with allowing 1.  The only time that an agent should 
strip a host report is when it knows it is the reacting node host-routed 
requests.
>
> Option 2 seems better to me, as it is the client that understands
> whether or not the host reports have value.
>
> <Ulrich>
> host reports in answers that correspond to realm-routed requests
> never have added value. Similarly, realm reports in answer messages that
> correspond to host-routed requestsnever have added value. See issue 3 below.
> </Ulrich>
SRD> How is it not good for a client to know about the fact that a 
server is overloaded?  How is it not good for a client to know that a 
realm is overloaded?  There is clear value for both cases, as the sooner 
a client learns about overload of a server or realm to which it sends 
requests the sooner the overload condition will be abated.

SRD> There might be times when an OLR isn't useful to a client/reacting 
node.  I disagree with the assertion that there is never added value.
>
>    For some applications the
> client might never send requests with a destination-host AVP. In this
> case the client can safely ignore the OLRs.  For applications where
> there is a mix of transaction types (host-routed and realm-routed), the
> client might choose to save all OLRs in the interest of better handling
> the overload for the requests that do include the destination-host AVP.
>
> <Ulrich>
> What do you mean with "better handling"?
> </Ulrich>
SRD> I mean that the sooner a reacting node learns about an overload 
condition the sooner the overload condition can be properly handled.
>
> Note that in this type of application, it will still work if the client
> ignores all host reports received on "realm-routed" transactions as the
> client will still receive a host report on host-routed transactions.
> This assumes that all answer messages have the OLR for the duration of
> the overload event.
>
> I suggest wording something like:
>
> A client MAY ignore OLRs of type host received in transactions where the
> request was realm-routed by the client.
>
> <Ulrich>
> ok, but also:
> "A client MAY ignore OLRs of type realm received in transactions where the
> request was host-routed by the client."
> (And maybe replace "client" with "reacting node")
> </Ulrich>
SRD> Yes, it should say reacting node.
>
> Note: In applications where there is a mix of realm-routed and
> host-routed requests it is recommended that the client save all host
> overload reports.
>
> <Ulrich>
> I would like to see all issues solved before recommending so.
> </Ulrich>
SRD> I don't understand issues 1 and 2.  I think my proposal addresses 
issues 3 and 4.
> Regards,
>
> Steve
>
> On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Ben,
>>
>> you  worte:
>> My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection.
>>
>> I think there in no need for the server to have this knowledge. The server simply puts its host-type OLR in the answer.
>> The agent that handled server selection receives this OLR and makes use of it for
>> a) diverting future realm routed request to other servers and
>> b) calculating an aggregated realm overload (taking into account the supported algorithm at the client).
>> This aggregated realm-type OLR is sent to the client.
>> Open question is whether in addition also the host-type OLR generated by the server is sent to the client. Issues identified so far are:
>> 1. Two OLRs in one answer must use the same algorithm resulting in the need for some kind of OLR conversion from one algorithm to another.
>> 2. Host type OLRs received by the client may easily get out of synch.
>> 3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-type request.
>> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used.
>>
>> Similar to this is another point recently questiond by JJ:
>> Whether an agent may insert a realm-type OLR to an answer which corresponds to a host-routed request, and which potentially already contains a host-type OLR. (This would only be possible if the agent supports the algorithm that was negotiated/selected between client and server).
>> Again I think that there is no added value as the client either has no need for the realm-type OLR (i.e. never sends realm-type requests to the realm) or will receive it with the response to the next sent realm-type request. And again there may be negative impacts for clients.
>>
>> As a way forward we may think about a way to convey both OLRs in one answer but clearly indicate which OLR is the "real thing" and which is the additional one. It must however be made clear that the additional one can savely be ignored by the reacting node.
>>
>> Ulrich
>>
>>
>>
>>    
>>    
>>
>>
>> -----Original Message-----
>> From: ext Ben Campbell [mailto:ben@nostrum.com]
>> Sent: Wednesday, September 10, 2014 10:35 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org
>> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
>>
>>
>> On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
>>
>>> Ben,
>>>
>>> please see comments inline.
>>>
>>> Ulrich
>>>
>>> -----Original Message-----
>>> From: ext Ben Campbell [mailto:ben@nostrum.com]
>>> Sent: Wednesday, September 10, 2014 4:38 AM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@ericsson.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org
>>> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example
>>>
>>> We had exactly that example in the draft discussed in Toronto ( draft-donovan-doic-agent-cases ).
>>>
>>> Comments inline:
>>>
>>> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
>>>
>>>> Dear JJacques,
>>>>
>>>> assume the following example:
>>>> In step 1 (realm routed request sent from Client to Agent), the client indicates that it supports loss.
>>>> In step 2 (host routed request send from agent to S1), the agent indicates that it supports loss and rate.
>>>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicates that it selected rate.
>>>>
>>>> Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition to the realm-type OLR of loss.
>>> I agree there is no point forwarding the OLR per se. However, the agent may still indicate that it supports "loss" back to the client, and send loss-based reports if the client sends too much traffic for the agent to comply with the max rate without throttling.
>>> <Ulrich> I think the agent shall indicate that it supports "loss" back to the client.
>> I wouldn't put it as strongly as "shall", but I think there are circumstances where it makes sense to do so. (see next comment). There may also be circumstances where it decides to handle OC control locally, in which case it may chose not to send any OC-O-F at all back to the client.
>>
>>> In addition, are you proposing that the agent may translate the rate based host-type OLR received from S1 into a loss based host type OLR and forward it to the client?</Ulrich>
>> Not quite. I would use the term "gateway" rather than "translate".
>>
>> I think it highly unlikely one can translate any given rate-based OLR into a loss-based OLR in a useful way. But, I do think that the agent may choose to locally enforce the rate limit, and send lost-based OLRs back to the client in an attempt to reduce the number of requests that the agent might have to throttle.
>>
>> For example, if the agent can achieve the rate limit at the current load offered by the client without throttling, it need send no OLRs to the client at all. In this case, the client doesn't need to know about the overload condition. But if the agent has to throttle, it might (maybe should) delegate the required throttling back to the client as much as it can. The loss algorithm is sort of clumsy for that purpose, but it would still be better than nothing.
>>
>>
>>>> Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answer "use loss for realm routed requests and rate for host routed requests"
>>> One approach is where you end up with is "loss" is supported between the client and agent, and "rate" is supported between the agent and server.
>>>
>>> Don't get me wrong, I'm not saying that's a _required_ approach, but it should be allowed.
>>> <Ulrich> I'm ok with "loss" for realm type OLRs sent from agent to client and "rate" for host type OLRs sent from Server to agent in this scenario (steps 8 and 7).
>>> However, if we allow an agent to translate a received host type OLR of "rate" into a sent host type OLR of "loss" we may end up in situations where the client receices out of sync OLRs from different agents on different paths between client and server.</Ulrich>
>> That's a good point. If your load is reasonably balanced across agents, it might not matter. If it _does_ matter, then something like an agent-overload report (as in Steve's draft) from the agent to the client might work better.
>>
>> I think we are going to need a better understanding of the rate algorithm to really specify how this should work. I just want to make sure we don't make  choices now that prevent us from solving that later.
>>
>>>> Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer).
>>>>
>>> I don't follow this. Do you mean "might never"? (I read "may never" as "is never allowed to").
>>> <Ulrich>yes sorry I meant "might never"</Ulrich>
>>>
>>> The agent has to ensure that any OLRs that get back to the client match the capabilities the client advertised, and received. It could do that by stripping all OC-S-F and OLR avps in answers
>>> <Ulrich>I agree</Ulrich>
>>> , or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side.
>>> <Ulrich> this sounds complex to me and is absolutely unnecessary</Ulrich>
>> I didn't say it had to, I said it could. I think it's a reasonable implementation choice that we should not forbid, but probably also should not require.
>>
>>>> I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the answer that corresponds to a realm type request.
>>> I don't see that following.
>>> <Ulrich> I did not say "shall forbid" but "should not mandate" </Ulrich>
>> I think others were arguing for "shall forbid".
>>
>>> We should prevent a server from putting any host reports into answers to realm routed requests. Otherwise, you have use cases that just want work.
>>> <Ulrich>how can a server receive a realm routed request? I can understand that a server may receive a request that does not contain a Destination-Host AVP, but that's not the definition of realm-routed request</Ulrich>
>> That's actually the point I was trying to make. If a node is a pure server, then by our current definition it never ever receives a realm-routed request. So a prohibition against having it put host-reports in responses to realm-routed requests is both non-constraining and non-sensical.
>>
>> Now, if a previous hop Agent handled server selection, then it's up to that agent whether to pass through an existing host-report, if the original request had been realm-routed from _its_ perspective.  We should neither require or forbid that.  (And I actually don't think that's specific to realm-routed requests. It's true for all request and report types.)
>>
>> But if we allow the agent to pass through a host-report, then the client must be prepared to receive it.
>>
>>
>>> For example, consider how a server could report any overload at all for an application that is exclusively realm-routed.
>>>
>>> Also, consider that with the recently discussed distinction between realm-routed requests and host-routed requests, we consider a request to be host-routed if it has a Destination-Host _or_ if a node has other knowledge that the request will go to specific server (e.g., if the peer-selection decision would send a request to the specific host. ) In the second case, the server itself cannot distinguish a host-routed request from a host-routed request.
>>> <Ulrich> I don't follow this. Do you mean "from a realm-routed request"?
>> Yes.
>>
>>> My interpretation of the definition is that a server will never receive a realm-routed request as the previous direct peer always has the knowledge that the request will go to that server.</Ulrich>
>> Agreed, so by the time the request gets to the server, it's host routed--even if it may have been previously realm-routed. I think we are proving the routing type to be at least somewhat hop-by-hop.
>>
>> My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection.
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime