Re: [Dime] Issue#35 conclusion

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 06 March 2014 09:11 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 B33F21A019C for <dime@ietfa.amsl.com>; Thu, 6 Mar 2014 01:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 GRzQUPWq4jwd for <dime@ietfa.amsl.com>; Thu, 6 Mar 2014 01:11:55 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 902171A01A9 for <dime@ietf.org>; Thu, 6 Mar 2014 01:11:38 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s269BWKJ007912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 10:11:32 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s269BVwn013721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 10:11:31 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Mar 2014 10:11:31 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 10:11:31 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/Xn9wvmyrSf2I+rd4YT2PBgAAVchQ
Date: Thu, 06 Mar 2014 09:11:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978A014@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.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5A68DEMUMBX014nsnin_"
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: 23643
X-purgate-ID: 151667::1394097092-00003660-A36503EE/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fJkrOoYw6czx3iab3eM5J0oHhuY
Subject: Re: [Dime] Issue#35 conclusion
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: Thu, 06 Mar 2014 09:12:00 -0000

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request reports. Can you please confirm.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.

Also proposal b)  impacts the reporting node which must not send client specific OLRs (with separate sequence number streams for different clients)

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type report to any non-DOIC-supporting client that is sending requests towards this host/realm.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but not Steve)  think it is "natural" and "implicit" that agents would do the per client behaviour as a default.


An alternative proposal that addresses the complexity argument for agents but at the same time at least partly addresses the 3GPP requirement would be to make use of a feature flag: clients allways set the flag, agents do not set the flag, reporting nodes may send client specific OLRs when the flag in the request was set. This has no big impact to clients (only always set the feature flag), no impacts to agents, and allows (if so desired) reporting nodes to make use of the client specific throttling (at least in some cases).

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for one specific client.
However, the discussion clarified that as it is the draft today, Host-report is sent from a reporting node towards the client from where it receives the request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the client (i.e. for a non-supporting client or for an agent SFE with topology hiding). In this case, the reporting node sends host-report to agent. Here we have two options:


a)      We expect the agent to apply the host-report received in an answer to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whether it prefers to apply this host-report to "all-client" vs "one-client". That increases again the complexity (at reporting node, protocol-wise, and at agent).



b)      We expect the agent to apply this host-report to any client that is sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increases robustness.

Therefore, I will be in favor of option b), which does not require any changes to the actual draft.

Let me know your opinions.
Best regards
/MCruz