Subject: [Dime] OVLI: comments to 4.3

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 5 Dec 2013 15:23:59 +0000

Dear all,

here are comments to clause 4.3:

1. Extensions in OC-OLR must either be mutually supported or must be ignorable. In the first case it is not enough for the reporting node to declare support of an extension in the sent OC-Feature-Vector AVP. For the second case there is no need to declare (or even define) support of an extension.
Proposal is to expand the second sentence as follows:

   OC-OLR may also be used to convey additional information about mutually supported extensions that are
   declared in the OC-Feature-Vector AVPs, and may also be used to convey additional ignorable information.

2. TimeStamp has been replaced with Sequence-Number. This has the negative impact that reacting nodes must calculate the expiration time base on OLR-reception time. OLR reception time and OLR creation time  may be significantly different.
I don't see any reason in favour of Sequence-Number. Proposal is to replace Sequence-Number with TimeStamp.

Best regards
Ulrich

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 6 Dec 2013 12:27:18 +0200

> 1. Extensions in OC-OLR must either be mutually supported or must be ignorable. In the first case it is not enough for the reporting node to declare support of an extension in the sent OC-Feature-V…

I am afraid I do not understand what you mean by above.

>    OC-OLR may also be used to convey additional information about mutually supportedextensions that are

Not sure about the wording "ignorable information".. but otherwise ok with me.

> I don’t see any reason in favour of Sequence-Number. Proposal is to replace Sequence-Number with TimeStamp.

I agree but you need to convince the others as well who favoured sequence number.

- Jouni

>  
> Best regards
> Ulrich
>  
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Dec 2013 13:39:36 +0000

Dear Jouni,

thanks again. 

Why isn't it so that others need to convince me/us?

Dear others,
Please let me know your arguments in favour of Sequence Number (if any).

Best regards
Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 11:27 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.3

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 6 Dec 2013 15:49:49 -0600

> I agree but you need to convince the others as well who favoured sequence number.

I don't think it was so much that we didn't want it to be a timestamp as we didn't want to mandate the implementation. We need to make sure the number changes between different versions. A time stamp is one way to do that. A sequence number (or version number) is another.

As I mentioned in a separate thread, we at list need to describe the expected properties. For example, the scope-of-uniqueness, whether we expect the number to always increase or just be different, etc. It's not clear to me that any association with wall clock time is one of those needed properties, even though a time stamp might be a perfectly reasonable way to achieve the other needed properties.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Sat, 7 Dec 2013 08:26:53 +0000

In my view, from the reacting point of view, Timestamp and Sequence-Number are both the same since it is just a number defining the uniqueness/version-Id of the OC-OLR.
e.g. we can define Sequence-Number and the reporting node can use Timestamp to populate the same. 

The most important part is that the reacting node is not supposed to use this parameter for anything but finding out the newness/version-ID of the report.
Beyond that, from the reporting node's point of view, I am fine to use Sequence-Number or Timestamp.

Regards,
Nirav.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 10:59:18 +0200

Ulrich,

> Why isn't it so that others need to convince me/us?

;-) Mainly because you brought it up.. and are currently
the one who wants this part to be changed.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 11:05:31 +0200

From the specification and implementation point of view sequence number
and timestamp _are_ different. If we choose to use timestamp we can refer
to exiting Diameter Time type, which then implies rules for NTP time. That
gives me exact guidelines how to implement overflows and such. For a sequence
number we need to define how e.g. values 0x00000001 and 0xfffffff7 relate to
each other. Is the former smaller compared to latter or a result of an overflow.
Also we need to define how initial values are picked up e.g. after a reboot of
a node.

I myself do not find random numbers useful at all. They do not provide me with
ordering semantics, which I might be interested in.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:55:11 +0000

Nirav,

it is also an important part that the reacting node calculates the expiry time of an OLR based on the included timestamp and duration and not based on the reception time and the included duration. It is much simpler for reporting nodes to include a pre-calculated OLR into the answer rather than  to adjust the validity-duration in the OLR in dependency of the time when the OLR is included into the answer. The reporting node may want the OLR to be valid starting from creation time (t0) for the validity-duration (d), i.e. until t0+d independent from the point in time (t0, t0+1,...,t0+d-1) when the OLR is sent.

Ulrich  

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Saturday, December 07, 2013 9:27 AM
To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.3

Regards,
Nirav.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Mon, 9 Dec 2013 11:06:42 +0000

Hello all,

I have no strong opinion on the Sequence-Number or TimeStamp. The key point is to uniquely identify the OLR, both work. Maybe we can add TimeStamp as an example which can be implemented as kind of Sequence-Number.

Best Regards,
Susan

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 6:27 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.3

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 13:37:19 +0200

Folks

Could we conclude on the sequence number vs. time stamp vs. something else?
We got more important places to spend our energy than this ;)

My proposal is the following (based on the original pre-00 design):

o We change the OC-Sequence-Number to OC-Time-Stamp in all occurrences
  in the -01.
o We use RFC6733 Time type for the OC-Time-Stamp. RFC6733 gives us
  already exact definition how to handle the AVP.
o Define that the OC-Time-Stamp is the time of the creation of the 
  "original" AVP within whose context the time stamp is present.
o The OC-Time-Stamp AVP uniqueness is still considered to be in scope
  of the communicating endpoints.
o The time stamp can be used to quickly determine if the content of
  the encapsulating AVP context has changed (among other properties).
  This would be useful specifically in the future when the encapsulating
  grouped AVPs  grow in size and functionality.

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 9 Dec 2013 12:43:33 +0000

Ulrich,

> it is also an important part that the reacting node calculates the expiry time of an OLR based on the included timestamp and duration and not based on the reception time and the included duration.
I do not agree that this is important.
I do not see any issue if the reacting node starts the timer equal to Validity-Period on reception of the message containing a fresh OC-OLR.
I agree that this means each reacting node will run this timer for different duration since each of them will start the timer of the same value but starting from the time when they received OC-OLR. But this is not an issue since Validity-Period is anyway a guestimate and it would provide a natural ramp up effect (to avoid message storm at the reporting node) if each of the reacting node stops the throttling at different time.

> It is much simpler for reporting nodes to include a pre-calculated OLR into the answer rather than  to adjust the validity-duration in the OLR in dependency of the time when the OLR is included into the answer.
I agree. The reporting node should not be required to adjust Validity-Period while sending OC-OLR to different reacting nodes. I do not see any need to do so based on my explanation above.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 4:25 PM
To: Nirav Salot (nsalot); Ben Campbell
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.3

Nirav,

Ulrich  

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Saturday, December 07, 2013 9:27 AM
To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.3

Regards,
Nirav.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 09 Dec 2013 10:00:02 -0600

Jouni,

I propose that we keep the name OC-Sequence-Number but that we use the
Time type for OC-Sequence-Number.  It is misleading and potentially
confusing to call it OC-Time-Stamp. 

We might consider expanding on the format of the AVP to make it
something like Session-ID, where it is a concatenation of the
Diameter-ID of the generating node and a timestamp.  This might help the
reacting node keep track of which sequence number it has received.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 16:24:42 -0600

> I agree that this means each reacting node will run this timer for different duration since each of them will start the timer of the same value but starting from the time when they received OC-OLR.…

Nirav and I agree on something for a change :-) The validity period is from the time you first get the OLR. It's not based on a timestamp in the message. The in-transit times for an OLR are not going to be so long, and the need for precision not so high, to justify the need for a time reference in the OLR.

> I agree. The reporting node should not be required to adjust Validity-Period while sending OC-OLR to different reacting nodes. I do not see any need to do so based on my explanation above.

This would only be an issue if we expect an overloaded node to keep the same overload state for relatively long periods of time. The nature of overload is such that I do not expect that to be true.

However, one point we need to be clear on is that receipt of a new copy of the same OLR does not restart the timer.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 16:34:42 -0600

On Dec 9, 2013, at 10:00 AM, Steve Donovan <[email-masked]> wrote:

> Jouni,
> 
> I propose that we keep the name OC-Sequence-Number but that we use the Time type for OC-Sequence-Number.  It is misleading and potentially confusing to call it OC-Time-Stamp.  
> 

I could live with that, although I would rather just define the expected properties of the sequence number, and leave the implementation up to the implementor. I assume your reasoning for not calling it a timestamp is that you do not want people to try to use it as a time base reference. If so, then we don't require any connection to a clock. We just need it to be monotonically increasing.

> We might consider expanding on the format of the AVP to make it something like Session-ID, where it is a concatenation of the Diameter-ID of the generating node and a timestamp.  This might help the reacting node keep track of which sequence number it has received.
> 

Do we need a uniqueness across multiple nodes property? If so, why?

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 09:28:09 +0200

Fine.. lets define then the sequence number semantics. Basic
unsigned integer math. The text proposal is the following:

4.4.  OC-Sequence-Number AVP

   The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
   Its usage in the context of the overload control is described in
   Sections 4.1 and 4.3.

   From the functionality point of view, the OC-Sequence-Number AVP
   MUST be used as a non-volatile increasing counter between two
   overload control endpoints.  The sequence number is only required
   to be unique between two overload control endpoints and does not
   need to be monotonically increasing.

   When comparing two sequence numbers, the new sequence number MUST
   be greater or equal than the old sequence number within a window
   that is half of the size of the maximum sequence number. This
   allows a simple handling of the sequence number overflow using
   unsigned integer arithmeticf:

     #define WINDOW 0x8000000000000000ULL
 
     bool verify_seqnum( uint64_t newsn, uint64_t oldsn ) {
         if (newsn - oldsn <= WINDOW)
             // newsn >= oldsn
             return true;   
         } else
             // outside window or newsn < oldsn
             return false;  
         }
     }

The above should even work is someone shovels NTP times into
sequence numbers with a blind typecasting.

- Jouni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 10 Dec 2013 10:12:12 +0000

Dear all,

See my comments below.
Best regards
MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: lunes, 09 de diciembre de 2013 23:25
To: Nirav Salot (nsalot)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.3

> I agree that this means each reacting node will run this timer for different duration since each of them will start the timer of the same value but starting from the time when they received OC-OLR.…

[Ben] Nirav and I agree on something for a change :-) The validity period is from the time you first get the OLR. It's not based on a timestamp in the message. The in-transit times for an OLR are not going to be so long, and the need for precision not so high, to justify the need for a time reference in the OLR.

[MCruz] I agree with Ben and Nirav, I think it is enough to start the validity period when the OLR is received by reacting node.

> I agree. The reporting node should not be required to adjust Validity-Period while sending OC-OLR to different reacting nodes. I do not see any need to do so based on my explanation above.

[Ben] This would only be an issue if we expect an overloaded node to keep the same overload state for relatively long periods of time. The nature of overload is such that I do not expect that to be true.
However, one point we need to be clear on is that receipt of a new copy of the same OLR does not restart the timer.

[MCruz] My understanding is that validity-period should be adjusted by reporting node depending on their expectations on traffic reduction by one client. Therefore, it should be updated towards _each_ client, based on reporting node expectations on _each_ client traffic reduction. I understand it does not mean (necessarily) that validity period has to be updated each time a message is sent, but it will depend on each overload situation and per client.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 12:18:06 +0200

> [MCruz] My understanding is that validity-period should be adjusted by reporting node depending on their expectations on traffic reduction by one client. Therefore, it should be updated towards _ea…

This is my understanding as well (and how the text currently is written.. or 
is meant to be read ;)

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 13:00:49 +0000

MCruz, Jouni,

> and per client

my understanding was that the differentiation _per_client_ was a requirement from 3GPP that is not covered by the DIOC base version and that requires an extension.

Note that the main problem is to cover cases where a single DOIC-supporting client performs overload mitigation on behalf of two different non-supporting clients.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 11:18 AM
To: Maria Cruz Bartolome
Cc: Ben Campbell; [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.3

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Tue, 10 Dec 2013 07:25:06 -0600

inline

> Do we need a uniqueness across multiple nodes property? If so, why?
Strictly speaking, no.  The thought was to make it similar to session-id
and potentially make it easier for the reacting node to keep
differentiate sequence numbers from different reporting nodes.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 14:31:43 +0000

Jouni,

1. I find the texts
a) "The sequence number ... does not need to be monotonically increasing"
and 
b) "...the new sequence number MUST be greater or equal than the old sequence number..."
contradicting.
Can you please clarify.

2. The expected behaviour when receiving an out-of-sequence sequence number within OC-OLR is described in 4.3:
   "The receiver SHOULD discard an OC-OLR AVP with a sequence number that is less than previously received one."
I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.

3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, December 10, 2013 8:28 AM
To: Ben Campbell; [email-masked] list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

 

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 14:43:48 +0000

Steve,

how does this work in scenarios where a non supporting client C sends some requests via the DOIC supporting agent A1 to the server S and other requests via a different DOIC supporting agent A2 to the same server S?

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 10, 2013 2:25 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

inline

On Dec 9, 2013, at 10:00 AM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

Jouni,

Do we need a uniqueness across multiple nodes property? If so, why?
Strictly speaking, no.  The thought was to make it similar to session-id and potentially make it easier for the reacting node to keep differentiate sequence numbers from different reporting nodes.

Steve

Folks

  in the -01.

- Jouni

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Dec 2013 09:03:07 -0600

I think that's close to correct. A couple of comments:

>   need to be monotonically increasing.

I think "increasing" and "monotonically increasing" mean the same thing. I believe the term we are looking for is "strictly increasing".

>   unsigned integer arithmeticf:

The MUST probably belongs in the generation side, not the comparison side. For comparison, we can say something like "a new sequence number is greater than a previous one if the new sequence number..."

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 23:31:13 +0200

Ulrich,

> a) "The sequence number ... does not need to be monotonically increasing"

Means the delta from old-seqno to new-seqno can be any non-negative integer
(within the given limits) not something fixed step/delta (like +1). As long as
"new-seqno >= old-seqno" holds we are fine.

> b) "...the new sequence number MUST be greater or equal than the old sequence number..."

See above. (mind the overflow case)

> I don't find this very robust. Once a higher sequence number (received erroneously by mistake) is accepted you cannot (easily) recover.

I find it more robust in a sense that I should not care about stale old information.
However, since we are piggybacking (by popular demand) we have little room for seqno
re-sync negotiation.

What is the mistake you refer here? A misbehaving implementation? In that case, it 
deserves to get a manual intervention once figured out by admins checking alarms and
logs. If the mistake is due other things, like endpoints being out of sync, we currently
have no written down mechanism to survive that.

> 3. The expected behaviour when receiving an out-of-sequence sequence number within the OC-Supported-Features AVP is not described. What is the intention here?

No intention. Just a sloppy specification. You are right that something needs to be
done & clarified here. (again the semantics of Time would nice..)

I'll propose something. Others should too ;)

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Dec 2013 15:36:16 -0600

> "new-seqno >= old-seqno" holds we are fine.

My understanding is that "new-seqno >= old-seqno" is the _definition_ of monotonically increasing.

But don't we want "new-seqno > old-seqno", that is, increase by a positive integer? (Assuming we are talking about a new OLR, not merely a copy of an old one.)

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 23:48:11 +0200

Ben,

> But don't we want "new-seqno > old-seqno", that is, increase by a positive integer? (Assuming we are talking about a new OLR, not merely a copy of an old one.)

Zero delta is there since, as far as I understood, replaying an
old (i.e. current) OLR or supported feature was desired functionality.

- jouni

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Dec 2013 15:56:12 -0600

> old (i.e. current) OLR or supported feature was desired functionality.

But that's not a new sequence number, is it? For that, the property is "old-seqno == old-seqno" :-)  The important thing is to ensure that, if the OLR is changed in any way, the new sequence number is incremented by a positive integer.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 11 Dec 2013 00:07:33 +0200

> But that's not a new sequence number, is it? For that, the property is "old-seqno == old-seqno" :-)  The important thing is to ensure that, if the OLR is changed in any way, the new sequence number…

Righty right.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 11 Dec 2013 07:21:02 +0000

Jouni,

ad 1. "monotonically" does not express your intention. What we are looking for may be "stepwise with fixed step".

Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the server would send back the realm-type OLR with sequence number s1. The next realm-type request sent by C (that survived the throttling) may take a path that does not include A1 but A2. A2 then selects the server and sends back a sequence number s2. Nothing ensures that s1 and s2 are in sequence.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 10:31 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; [email-masked] list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

- Jouni

---

From: Jouni <[email-masked]>
Date: Wed, 11 Dec 2013 09:37:39 +0200

Ulrich,

> Ad 2. Is not necessarily a mistake that could result in out-of-sequence sequence numbers. When a client C sends a realm-type requests towards any server in the realm, an agent A1 that selects the s…

Would the server in both cases (via A1 and A2) be the same?

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 11 Dec 2013 07:43:17 +0000

That's not predictable. It may be the same server in some cases, and different servers in other cases.

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Wednesday, December 11, 2013 8:38 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; [email-masked] list; Steve Donovan
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

- Jouni

---

From: Jouni <[email-masked]>
Date: Wed, 11 Dec 2013 10:15:55 +0200

Ulrich,

I might be slow but.. Section 4.4 says

   control endpoints.  The sequence number is only required to be unique
   between two overload control endpoints and does not need to be

Unique between two endpoints..

Section 5.1 talks about endpoints:

   of an arbitrary Diameter network.  The overload control information
   is exchanged over on a "DOIC association" between two communication
   endpoints.  The endpoints, namely the "reacting node" and the
   "reporting node" do not need to be adjacent Diameter peer nodes, nor

So if your agents inject realm reports, they need to be endpoints to the
client. Similar to Figure 5. Therefore the sequence number spaces between
C-A1 and C-A2 are separate.

Now it is not clear to me, whether in your reasoning the C would see
the server identity (as the endpoint) when there is an active "DEP
agent" on the path. That would not clearly work and not be align with
the endpoint assumption.

Note that at some point of time we had (at least on a discussion level
in f2f meeting) report originator identity in the OLR. That would make
endpoint identification trivial. Now a "DEP agent" needs to act as a 
"server" for its clients in order to appear as an endpoint.

- Jouni

ps: still think the use of Time is simpler..

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 07:13:35 -0600

Jouni,

We need the sequence number to be strictly increasing.  I don't see the
need for it to increase in uniform amounts.  Using time does fit these
requirements.  I'm ok with using time as long as we don't call the AVP
timestamp.

Ulrich does bring up an interesting use case, where a client is
receiving realm reports for the same realm from different agents.  We
need to define the clients behavior in this case. 

Presumably the client needs to be able to determine who generated the
realm report.  This cannot be determine based on the content of the
message or the connection on which the message arrived.  It seems like
we might need "Report Generator Diameter ID" in the overload report
specifically for Realm reports. 

Once the client is able to differentiate between realm reports sent by
different agents (or servers) we need logic defining how the client
deals with a new overload report. 

I see a couple of options (others will probably see options I am missing):

- Use the last received realm report - This introduces the possibility
of thrashing between two different reduction values and different
durations.  Note that this approach does not require the source of the
report to be included in the report.

- Only listen to one source of realm overload - The approach would be to
remember who sent the first overload report from the realm and ignore
realm overload reports from other sources.  This behavior would likely
be constrained to a single occurrence of realm overload.  Meaning that
the "memory" of the report source would only last as long as that
overload event persists.  Once the overload event goes away, the report
source would be forgotten and a new source could be used for the next
occurrence.

On the surface, the second approach looks better to me.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 07:45:18 -0600

Ulrich,

Is your question how sequence numbers work when there are DOIC
supporting agents?

The capabilities exchange is between two DOIC endpoints, so in the case
you outline, the server would see capability information from each agent
in the path.  The server should not see the sequence numbers from the
clients.

This does point out that we are likely missing something from the
OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter ID
included in that AVP.

Steve

On 12/10/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> how does this work in scenarios where a non supporting client C sends
> some requests via the DOIC supporting agent A1 to the server S and
> other requests via a different DOIC supporting agent A2 to the same
> server S?
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, December 10, 2013 2:25 PM
> *To:* Ben Campbell
> *Cc:* [email-masked] list
> *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:
> comments to 4.3
>
>  
>
> inline
>
>     On Dec 9, 2013, at 10:00 AM, Steve Donovan <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>         Jouni,
>
>          
>
> Strictly speaking, no.  The thought was to make it similar to
> session-id and potentially make it easier for the reacting node to
> keep differentiate sequence numbers from different reporting nodes.
>
>  
>  
>
>     Steve
>
>      
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 11 Dec 2013 15:50:26 +0000

Steve,

> Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.
Why should the realm report be different - irrespective if they are sent by two agents or one agent?

If multiple agents are sending report for the same realm, there should be some coordination between those agents to generate common view of the realm they are serving.

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Wednesday, December 11, 2013 6:44 PM
To: Jouni; Wiehe, Ulrich (NSN - DE/Munich)
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Jouni,

We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we don't call the AVP timestamp.

Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.

Presumably the client needs to be able to determine who generated the realm report.  This cannot be determine based on the content of the message or the connection on which the message arrived.  It seems like we might need "Report Generator Diameter ID" in the overload report specifically for Realm reports.

Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.

- Use the last received realm report - This introduces the possibility of thrashing between two different reduction values and different durations.  Note that this approach does not require the source of the report to be included in the report.

- Only listen to one source of realm overload - The approach would be to remember who sent the first overload report from the realm and ignore realm overload reports from other sources.  This behavior would likely be constrained to a single occurrence of realm overload.  Meaning that the "memory" of the report source would only last as long as that overload event persists.  Once the overload event goes away, the report source would be forgotten and a new source could be used for the next occurrence.

Steve

Ulrich,

the endpoint assumption.

- Jouni

-----Original Message-----

Cc: Ben Campbell; [email-masked]<mailto:[email-masked]> list; Steve Donovan

Ulrich,

Jouni,

- Jouni

Ulrich

-----Original Message-----

Cc: Ben Campbell; [email-masked]<mailto:[email-masked]> list; Steve Donovan

Ulrich,

On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Jouni,

1. I find the texts

and

contradicting.

Can you please clarify.

re-sync negotiation.

- Jouni

Ulrich

-----Original Message-----

To: Ben Campbell; [email-masked]<mailto:[email-masked]> list; Steve Donovan

Sections 4.1 and 4.3.

          // newsn >= oldsn

          return true;

      } else

          return false;

      }

  }

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell <[email-masked]><mailto:[email-masked]> wrote:

Jouni,

Steve

Folks

in the -01.

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 11 Dec 2013 17:53:44 +0200

Steve,

> We need the sequence number to be strictly increasing.  I don't see the need for it to increase in uniform amounts.  Using time does fit these requirements.  I'm ok with using time as long as we do…

Ok.

> Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

Could we simply say that in this case the agents (or who ever inserts the realm report)
MUST share the same view of the realm overload condition? Obviously how it is achieved 
would be implementation specific. I recall we have surfaced this topic earlier..

- Jouni

>>> From: ext Jouni [
>>> mailto:[email-masked]
>>> ] 
>>>  list; Steve Donovan
>>>> From: ext Jouni Korhonen [
>>>> mailto:[email-masked]
>>>> ] 
>>>>  list; Steve Donovan
>>>> On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>>>> <[email-masked]>
>>>>  wrote:
>>>> 
>>>> 
>>>>> Jouni,
>>>>> 
>>>>> 1. I find the texts
>>>>> From: DiME [
>>>>> mailto:[email-masked]
>>>>> ] On Behalf Of ext Jouni Korhonen
>>>>> To: Ben Campbell; 
>>>>> [email-masked]
>>>>>  list; Steve Donovan
>>>>> On Dec 10, 2013, at 12:34 AM, Ben Campbell 
>>>>> <[email-masked]>
>>>>>  wrote:
>>>>> 
>>>>>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 11 Dec 2013 17:22:29 +0000

Dear all,

> [Steve] Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

[Jouni] Could we simply say that in this case the agents (or who ever inserts the realm report) MUST share the same view of the realm overload condition? Obviously how it is achieved would be implementation specific. I recall we have surfaced this topic earlier..

[MCruz] But... isn't simpler to use time instead of sequence? It would solve this case as long as any number of agents serving same realm are time synchronized.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 11 Dec 2013 23:38:54 +0200

Hi,

> [MCruz] But... isn't simpler to use time instead of sequence? It would solve this case as long as any number of agents serving same realm are time synchronized.  

Well.. time is what I have been preferring. Now Steve is also OK with that
as long as we do not name is as a "timestamp".

Just to note that clocks typically get synchronized using NTP. That would
equal to central sequence number source with some local skew tolerance ;-)

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 09:24:14 +0000

Steve,

not sure if I correctly understand your second paragraph; please see inline.

Anyway I agree with your conclusion: Something is missing in the concept of "sequence-number in OC-Supported-Features". We WOULD need the DOIC end-point Diameter ID included in that AVP. I said WOULD because things are becoming more and more complex and complicated. This all is not worth the effort.  Let's remove sequence number from Supported-Features.

A Reporting node that does not support any extension (i.e. supports only OLR_DEFAULT_ALGO)  only needs to know whether there is a reacting node down stream that supports OLR_DEFAULT_ALGO    in order to decide whether or not a pre-calculated (default-algo-type) OLR must be returned or not. This can simply be done by checking bit 0 of the received Feature-Vector.
The alternative

-          to setup and maintain a database of DOIC end-point ID / sequence-number pairs containing the pre-calculated (last-known-supported-feature-type) OLR , and

-          to check, when receiving a request, whether the included DOIC end-point ID / sequence-number pair is present in the database and if so return the corresponding OLR;
is over-overkill.

Also there is no need for the reporting node (which still only supports OLR_DEFAULT_ALGO ) to detect that the reacting nodes capabilities have been updated e.g. from "support of   OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT_ALGO   and   OLR_SOMETHING_NEW "

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, December 11, 2013 2:45 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

Is your question how sequence numbers work when there are DOIC supporting agents?
[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one DOIC supporting agents that do DOIC on behalf of a (single) non-DOIC-supporting Client.

The capabilities exchange is between two DOIC endpoints,
[Wiehe, Ulrich (NSN - DE/Munich)] I agree
so in the case you outline, the server would see capability information from each agent in the path
[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability information in a received request but does not know which downstream node included the capability information. Not more than one node in a path will incude capability information.
.  The server should not see the sequence numbers from the clients.
[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one client, and that does not support DOIC, so I don't understand "sequence numbers from the clients"

This does point out that we are likely missing something from the OC-Feature-Vector AVP.  We likely need the DOIC end-point Diameter ID included in that AVP.

Steve

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 10, 2013 2:25 PM
To: Ben Campbell
Cc: [email-masked]<mailto:[email-masked]> list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

inline

Jouni,

Steve

Folks

  in the -01.

- Jouni

DiME mailing list

DiME mailing list

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 10:29:23 +0000

Jouni,

I dont find it acceptable to say "well, the concept of real-type OLRs has unresolved issues; implementatios are expected to resolve those."
Also, there may be deployments where agent A1 has connections to Servers S1 and S2 but not S3, A2 has connections to S1 and S3 but not S2, A3 has connections to S1 and S3 but not S2.

Note there are still other open issue of realm type concept e.g. like partitioned servers.

MCruz,
I'm afraid TimeStamp does not help. Even if the agents are 100% time synchronized it is not guaranteed that all agents will go into the (same) overload state exactly at the same time. Also: with the deployment scenario outlined above different agents  may be in different overload states.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, December 11, 2013 6:22 PM
To: Jouni Korhonen; Steve Donovan
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Dear all,

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 12 Dec 2013 12:58:05 +0200

Ulrich,

> I dont find it acceptable to say "well, the concept of real-type OLRs has unresolved issues; implementatios are expected to resolve those."

If you need synchronisation for one thing.. then you achieve it
somehow. Just like in you example how you would keep realm reports
in sync between agents? It is equivalent issue unless you are fine
with conflicting reports..

It is not necessarily our job to define how some things at the 
deployment level are achieved. We already made rather rough 
assumptions how front ends and such work.

> Also, there may be deployments where agent A1 has connections to Servers S1 and S2 but not S3, A2 has connections to S1 and S3 but not S2, A3 has connections to S1 and S3 but not S2.

So? How would that change the situation? The realm status should 
be the same for all reports representing the same realm.

> I'm afraid TimeStamp does not help. Even if the agents are 100% time synchronized it is not guaranteed that all agents will go into the (same) overload state exactly at the same time. Also: with th…

So now you are saying that it would be acceptable that multiple
sources (agents) from the same realm tell different truth about
the realm state to the reacting node? I would find that somewhat 
unacceptable assumption.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 12 Dec 2013 13:36:18 +0200

Steve,

> Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

Any suggestions? I mean agents may have hugely different view of the
realm if they are acting on their own.

> Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  

I need now to check one of the basic assumptions on DOIC now
so that we have the same understanding. I went back to the
endpoint text in Section 5.1. There, for example in Figures 
4 and 5 the DOIC association and the endpoint assumption does
does not work IMHO because we have no endpoint identity in the
OLR. In order the endpoint assumption to work (as I drew it on
the white board in Porto), it would require as many Diameter
level sessions as there are DOIC associations.

So.. has assumptions shifted in a meanwhile and I have just
not paid attention?

> On the surface, the second approach looks better to me.

Or add the identity of the OLR originator explicitly if it
cannot be determined implicitly (i.e. from the Diameter
message's Origin-Host/Realm).

Or assume the endpoint really is the endpoint in DOIC and
Diameter session sense.

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 12 Dec 2013 12:40:48 +0000

All,

I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.
Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.
What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Thursday, December 12, 2013 5:06 PM
To: Steve Donovan
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Steve,

> Ulrich does bring up an interesting use case, where a client is receiving realm reports for the same realm from different agents.  We need to define the clients behavior in this case.  

Any suggestions? I mean agents may have hugely different view of the realm if they are acting on their own.

> Once the client is able to differentiate between realm reports sent by different agents (or servers) we need logic defining how the client deals with a new overload report.  

I need now to check one of the basic assumptions on DOIC now so that we have the same understanding. I went back to the endpoint text in Section 5.1. There, for example in Figures
4 and 5 the DOIC association and the endpoint assumption does does not work IMHO because we have no endpoint identity in the OLR. In order the endpoint assumption to work (as I drew it on the white board in Porto), it would require as many Diameter level sessions as there are DOIC associations.

So.. has assumptions shifted in a meanwhile and I have just not paid attention?

> On the surface, the second approach looks better to me.

Or add the identity of the OLR originator explicitly if it cannot be determined implicitly (i.e. from the Diameter message's Origin-Host/Realm).

Or assume the endpoint really is the endpoint in DOIC and Diameter session sense.

- Jouni

>> So if your agents inject realm reports, they need to be endpoints to 
>> the client. Similar to Figure 5. Therefore the sequence number spaces 
>> between
>> Note that at some point of time we had (at least on a discussion 
>> level in f2f meeting) report originator identity in the OLR. That 
>> would make endpoint identification trivial. Now a "DEP agent" needs 
>> to act as a "server" for its clients in order to appear as an endpoint.
>> 
>> - Jouni
>> 
>>>> Means the delta from old-seqno to new-seqno can be any non-negative 
>>>> integer (within the given limits) not something fixed step/delta 
>>>> (like +1). As long as "new-seqno >= old-seqno" holds we are fine.
>>>> 
>>>> 
>>>> However, since we are piggybacking (by popular demand) we have 
>>>> little room for seqno re-sync negotiation.
>>>> 
>>>> What is the mistake you refer here? A misbehaving implementation? 
>>>> In that case, it deserves to get a manual intervention once figured 
>>>> out by admins checking alarms and logs. If the mistake is due other 
>>>> things, like endpoints being out of sync, we currently have no written down mechanism to survive that.
>>>> 
>>>> 
>>>> No intention. Just a sloppy specification. You are right that 
>>>> something needs to be done & clarified here. (again the semantics 
>>>> of Time would nice..)
>>>>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 07:59:05 -0600

Ulrich,

I don't understand your last statement.  How do new algorithms or
features get introduced to a network if the reporting node does not
detect that reacting nodes start supporting new features.

As I've said in other messages, the sequence number does not force
anyone to keep a state database.  It allows it but does not require it.

Steve

On 12/12/13 3:24 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Anyway I agree with your conclusion: Something is missing in the
> concept of "sequence-number in OC-Supported-Features". We WOULD need
> the DOIC end-point Diameter ID included in that AVP. I said WOULD
> because things are becoming more and more complex and complicated.
> This all is not worth the effort.  *Let's remove sequence number from
> Supported-Features*.
>
>  
>
> A Reporting node that does not support any extension (i.e. supports
> only OLR_DEFAULT_ALGO)  only needs to know whether there is a reacting
> node down stream that supports OLR_DEFAULT_ALGO    in order to decide
> whether or not a pre-calculated (default-algo-type) OLR must be
> returned or not. This can simply be done by checking bit 0 of the
> received Feature-Vector.
>
> The alternative
>
> -          to setup and maintain a database of DOIC end-point ID /
> sequence-number pairs containing the pre-calculated
> (last-known-supported-feature-type) OLR , and
>
> -          to check, when receiving a request, whether the included
> DOIC end-point ID / sequence-number pair is present in the database
> and if so return the corresponding OLR;
>
> is over-overkill.
>
>  
>
> Also there is no need for the reporting node (which still only
> supports OLR_DEFAULT_ALGO) to detect that the reacting nodes
> capabilities have been updated e.g. from "support of  
> OLR_DEFAULT_ALGO" to "support of  OLR_DEFAULT_ALGO   and
>   OLR_SOMETHING_NEW"
>
>  
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:[email-masked]]
> *Sent:* Wednesday, December 11, 2013 2:45 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
> *Cc:* [email-masked] list
> */[Wiehe, Ulrich (NSN - DE/Munich)] yes, when there are more than one
> DOIC supporting agents that do DOIC on behalf of a (single)
> non-DOIC-supporting Client./*
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] I agree/*
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] the server would see capability
> information in a received request but does not know which downstream
> node included the capability information. Not more than one node in a
> path will incude capability information./*
>
> */[Wiehe, Ulrich (NSN - DE/Munich)] in the example there is only one
> client, and that does not support DOIC, so I don't understand
> "sequence numbers from the clients"/*
>
>
>
>     how does this work in scenarios where a non supporting client C
>     sends some requests via the DOIC supporting agent A1 to the server
>     S and other requests via a different DOIC supporting agent A2 to
>     the same server S?
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Steve Donovan
>     *Cc:* [email-masked] <mailto:[email-masked]> list
>     *Subject:* Re: [Dime] Conclusion for Sequence Numbers - was Re:
>     OVLI: comments to 4.3
>
>      
>
>     inline
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 08:02:53 -0600

Even if we state that senders of realm reports should only send
synchronized information, the protocol still needs to handle the
situation where the information isn't synchronized.  Otherwise we face
the potential for thrashing.

I also don't think we can make the broad assumption that all Diameter
networks are going to properly use NTP. 

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 08:13:16 -0600

See inline.

Steve
> realm if they are acting on their own.
I think it is ok to say that senders of Realm reports should attempt to
send the same information.  I don't however, think this is sufficient. 
There are likely to be lags in exchanging of information between agents
sending the Realm reports. 

As I said in another email, I think we need to define the behavior for a
reacting node that receives realm reports from multiple sources.  This
probably requires including the endpoint ID in the reports.
> So.. has assumptions shifted in a meanwhile and I have just
SRD> I don't know if it has drifted or if people walked away with
different understandings.  We are just working through behavior text,
which is needed to fully understand the concept.  I do think we need
endpoint ID in the report, as mentioned above.
> message's Origin-Host/Realm).
Yes, it might work to only require the end-point ID in realm reports.
> Or assume the endpoint really is the endpoint in DOIC and
Please explain what you mean here.  I don't understand how making
sessions and associations the same helps.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 08:20:26 -0600

Nirav,

See inline.

Steve

> I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.
We can make the statement that all senders of realm reports should send
the same report.  This does not guarantee that it will always happen. 
If agents are sending the report, they are generally distributed
elements.  In very large networks, this distribution can span
continents.  There will be a lag in the "synchronization" of the realm
overload information.

My concern is that we have well defined behavior for when a reactor
receives conflicting realm reports.  We need to avoid thrashing between
different reduction levels, which could make the overload situation worse.
> Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.
Adding the endpoint identity is needed to allow the reacting node to
know that it is receiving two different views of Realm overload from two
different reporting end-points.
> What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?
One proposal for how we deal with the fact that different reports can
have different values is to have the reacting node treat the first
reporting node as the authority for reporting realm overload state for
that overload instance.  In this case, the reacting node would ignore
reports received from other reporting nodes. In order to ignore reports
from non authoritative endpoints requires the reacting node to know
which endpoints send which reports.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 15:32:45 +0000

Steve,

Why would a reporting node that only supports OLR_DEFAULT_ALGO  and does not support any other feature need to detect that a reacting node supports lots of new features in addition to OLR_DEFAULT_ALGO ? Even if it dectets support of new features by the reacting node, the reporting node would not behave any differently than before detecting this.

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 2:59 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

I don't understand your last statement.  How do new algorithms or features get introduced to a network if the reporting node does not detect that reacting nodes start supporting new features.

As I've said in other messages, the sequence number does not force anyone to keep a state database.  It allows it but does not require it.

Steve

Ulrich

Ulrich,

Steve

Ulrich

inline

Jouni,

Steve

Folks

  in the -01.

- Jouni

DiME mailing list

DiME mailing list

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 12 Dec 2013 16:26:01 +0000

Steve,

So as I understand it is not a common case for different agent to provide different view of the same realm and this may have happen during a small window when synchronization has not taken place between the geographically distributed agents.
Right?

If so, I can understand the following part of your proposal.
One proposal for how we deal with the fact that different reports can have different values is to have the reacting node treat the first reporting node as the authority for reporting realm overload state for that overload instance.

i.e. I can understand to define some behavior for the reacting node to handle the case (which is anyway rare case) when two agents provide different realm-report for the same report.
The behavior could be simply to consider only the last report when two agents have sent two different reports of the same realm. (And this will also work when the same agent has sent two different realm-reports, purposefully - e.g. due to the change in the realm overload).
But this still does not require adding of agent's identity in the overload-report.

Regards,
Nirav.

From: Steve Donovan [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 7:50 PM
To: Nirav Salot (nsalot); Jouni Korhonen
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Nirav,

See inline.

Steve

All,

I do not understand this discussion regarding different agents of the same realm having different view of the realm and provide different overload report.
We can make the statement that all senders of realm reports should send the same report.  This does not guarantee that it will always happen.  If agents are sending the report, they are generally distributed elements.  In very large networks, this distribution can span continents.  There will be a lag in the "synchronization" of the realm overload information.

My concern is that we have well defined behavior for when a reactor receives conflicting realm reports.  We need to avoid thrashing between different reduction levels, which could make the overload situation worse.

Additionally, I also do not understand the proposal of adding identity of the agent generating "realm report" into the report.
Adding the endpoint identity is needed to allow the reacting node to know that it is receiving two different views of Realm overload from two different reporting end-points.

What is the use of this identity at the reacting node when the report is realm report? Why should the reacting node care who generated the realm report?
One proposal for how we deal with the fact that different reports can have different values is to have the reacting node treat the first reporting node as the authority for reporting realm overload state for that overload instance.  In this case, the reacting node would ignore reports received from other reporting nodes. In order to ignore reports from non authoritative endpoints requires the reacting node to know which endpoints send which reports.

Regards,

Nirav.

-----Original Message-----

To: Steve Donovan

Cc: Ben Campbell; [email-masked]<mailto:[email-masked]> list

Steve,

On Dec 11, 2013, at 3:13 PM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

Jouni,

- Jouni

Steve

Ulrich,

   "reporting node" do not need to be adjacent Diameter peer nodes,

nor

between

the endpoint assumption.

- Jouni

-----Original Message-----

From: ext Jouni [

]

Cc: Ben Campbell;

[email-masked]<mailto:[email-masked]>

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3

Ulrich,

Jouni,

- Jouni

Ulrich

-----Original Message-----

]

Cc: Ben Campbell;

[email-masked]<mailto:[email-masked]>

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI:

comments to 4.3

Ulrich,

<[email-masked]><mailto:[email-masked]>

 wrote:

Jouni,

1. I find the texts

and

contradicting.

Can you please clarify.

of Time would nice..)

- Jouni

Ulrich

-----Original Message-----

From: DiME [

To: Ben Campbell;

[email-masked]<mailto:[email-masked]>

 list; Steve Donovan

Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re:

OVLI: comments to 4.3

Sections 4.1 and 4.3.

          // newsn >= oldsn

          return true;

      } else

          return false;

      }

  }

- Jouni

On Dec 10, 2013, at 12:34 AM, Ben Campbell <[email-masked]><mailto:[email-masked]>

 wrote:

On Dec 9, 2013, at 10:00 AM, Steve Donovan <[email-masked]><mailto:[email-masked]>

 wrote:

Jouni,

Steve

Folks

in the -01.

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 13 Dec 2013 09:05:57 +0000

Steve,

another approach is to let the reacting node indicate Ongoing-Throttling-Information in requests. Based on that agents will not return out of sync OLRs.
e.g. client C sends 1st realm type request which is routed via agent A1. A1 returns OLR requesting 10% reduction with sequence number s. C sends a 2nd realm type request (which survived the 10% throttling and indicates so in the request) which is routed via agent A2. Since it is assumed that A2 would also require  a 10% reduction and A2 detects that C is already doing a 10% reduction, there is no need for A2 to return an OLR which potentially would have an out-of-sync sequence number.
We could also allow the agents to accept a limited deviation in the percentage, i.e. if A2 would want a reduction of 9% it still could accept the 2nd request and not return an OLR.

Ulrich

Sent: Wednesday, December 11, 2013 2:14 PM

Jouni,

Steve

Ulrich,

the endpoint assumption.

- Jouni

-----Original Message-----

Ulrich,

Jouni,

- Jouni

Ulrich

-----Original Message-----

Ulrich,

Jouni,

1. I find the texts

and

contradicting.

Can you please clarify.

re-sync negotiation.

- Jouni

Ulrich

-----Original Message-----

Sections 4.1 and 4.3.

          // newsn >= oldsn

          return true;

      } else

          return false;

      }

  }

- Jouni

Jouni,

Steve

Folks

in the -01.

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 13 Dec 2013 12:12:58 +0000

Jouni,

again, I don't find this acceptable. 

See inline.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Thursday, December 12, 2013 11:58 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Maria Cruz Bartolome; Steve Donovan; Ben Campbell; [email-masked] list
Subject: Re: [Dime] Conclusion for Sequence Numbers - was Re: OVLI: comments to 4.3

Ulrich,

[Wiehe, Ulrich (NSN - DE/Munich)] I'm not fine with conflicting reports, but the current solution for DOIC will result in conflicting reports in some deployments. I propose to update the solution so that it solves the identified problems for these deployments.

It is not necessarily our job to define how some things at the 
deployment level are achieved. We already made rather rough 
assumptions how front ends and such work.
[Wiehe, Ulrich (NSN - DE/Munich)] It is our job to make DOIC a success. It will not be a success when it cannot be used in certain deployments.

So now you are saying that it would be acceptable that multiple
sources (agents) from the same realm tell different truth about
the realm state to the reacting node? I would find that somewhat 
unacceptable assumption.
[Wiehe, Ulrich (NSN - DE/Munich)] I don't say that this is acceptable; I say that this may be the result in the current solution and we need to enhance the solution to cover those cases.

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 06:16:39 -0600

Nirav,

The issue with considering only the last report is that it introduces
the potential for thrashing between different values.  This could make
the overload event even worse.

I agree that this should be a rare case.  I still think, however, that
we need to have defined behavior.

One other argument for including the sender of the overload report in
the report itself is security.  The ability of a bad actor to insert a
malicious overload report can be a very effective DOS attack.  I know we
have said we aren't addressing security yet but this seems pretty short
sighted.  Being able to establish that the identity of the sender of an
overload report will be an important part of the security solution.  We
should take this step in that direction.

Steve

On 12/12/13 10:26 AM, Nirav Salot (nsalot) wrote:
>
> Steve,
>
>  
>
> So as I understand it is not a common case for different agent to
> provide different view of the same realm and this may have happen
> during a small window when synchronization has not taken place between
> the geographically distributed agents.
>
> Right?
>
>  
>
> that overload instance.
> i.e. I can understand to define some behavior for the reacting node to
> handle the case (which is anyway rare case) when two agents provide
> different realm-report for the same report.
>
> The behavior could be simply to consider only the last report when two
> agents have sent two different reports of the same realm. (And this
> will also work when the same agent has sent two different
> realm-reports, purposefully -- e.g. due to the change in the realm
> overload).
>
> *From:*Steve Donovan [mailto:[email-masked]]
> *Sent:* Thursday, December 12, 2013 7:50 PM
> *To:* Nirav Salot (nsalot); Jouni Korhonen
> *Cc:* Ben Campbell; [email-masked] list
> We can make the statement that all senders of realm reports should
> send the same report.  This does not guarantee that it will always
> happen.  If agents are sending the report, they are generally
> distributed elements.  In very large networks, this distribution can
> span continents.  There will be a lag in the "synchronization" of the
> realm overload information.
>
> receives conflicting realm reports.  We need to avoid thrashing
> between different reduction levels, which could make the overload
> situation worse.
>
>  
> know that it is receiving two different views of Realm overload from
> two different reporting end-points.
>
>  
> reports received from other reporting nodes. In order to ignore
> reports from non authoritative endpoints requires the reacting node to
> know which endpoints send which reports.
>
>  
>  
> Regards,
> Nirav.
>  
> Cc: Ben Campbell; [email-masked] <mailto:[email-masked]> list
> On Dec 11, 2013, at 3:13 PM, Steve Donovan <[email-masked]> <mailto:[email-masked]> wrote:
>  
>
>     Jouni,
>
>      
>
>             [email-masked] <mailto:[email-masked]>
>
>              list; Steve Donovan
>
>                 [email-masked] <mailto:[email-masked]>
>
>                  list; Steve Donovan
>
>                 <[email-masked]> <mailto:[email-masked]>
>
>                  wrote:
>
>                  
>
>                  
>
>                     Jouni,
>
>                      
>
>                     1. I find the texts
>
>                     [email-masked] <mailto:[email-masked]>
>
>                      list; Steve Donovan
>
>                     On Dec 10, 2013, at 12:34 AM, Ben Campbell <[email-masked]> <mailto:[email-masked]>
>
>                      wrote:
>
>                      
>
>                      
>
>                         On Dec 9, 2013, at 10:00 AM, Steve Donovan <[email-masked]> <mailto:[email-masked]>
>
>                          wrote:
>
>                          
>
>                          
>
>                             Jouni,
>
>                              
>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 07:34:19 -0600

Ulrich,

I can see how Ongoing-Throttling-Information could be used to help
agents understand the overload state being sent by other agents.  I
don't, however, think it is a complete solution.

In addition, Ongoing-Throttling-Information is not part of the solution,
at least not yet. 

We need to find a way to drive these discussions to conclusions.

Steve

On 12/13/13 3:05 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> another approach is to let the reacting node indicate
> Ongoing-Throttling-Information in requests. Based on that agents will
> not return out of sync OLRs.
>
> e.g. client C sends 1^st realm type request which is routed via agent
> A1. A1 returns OLR requesting 10% reduction with sequence number s. C
> sends a 2^nd realm type request (which survived the 10% throttling and
> indicates so in the request) which is routed via agent A2. Since it is
> assumed that A2 would also require  a 10% reduction and A2 detects
> that C is already doing a 10% reduction, there is no need for A2 to
> return an OLR which potentially would have an out-of-sync sequence number.
>
> We could also allow the agents to accept a limited deviation in the
> percentage, i.e. if A2 would want a reduction of 9% it still could
> accept the 2^nd request and not return an OLR.
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
> *Sent:* Wednesday, December 11, 2013 2:14 PM
> *To:* Jouni; Wiehe, Ulrich (NSN - DE/Munich)
> We need the sequence number to be strictly increasing.  I don't see
> the need for it to increase in uniform amounts.  Using time does fit
> these requirements.  I'm ok with using time as long as we don't call
> the AVP timestamp.
>
> - Only listen to one source of realm overload - The approach would be
> to remember who sent the first overload report from the realm and
> ignore realm overload reports from other sources.  This behavior would
> likely be constrained to a single occurrence of realm overload. 
> Meaning that the "memory" of the report source would only last as long
> as that overload event persists.  Once the overload event goes away,
> the report source would be forgotten and a new source could be used
> for the next occurrence.
>
>         Cc: Ben Campbell; [email-masked] <mailto:[email-masked]> list; Steve Donovan
>
>             Cc: Ben Campbell; [email-masked] <mailto:[email-masked]> list; Steve Donovan
>
>             On Dec 10, 2013, at 4:31 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>              
>
>                 Jouni,
>
>                  
>
>                 1. I find the texts
>
>                 To: Ben Campbell; [email-masked] <mailto:[email-masked]> list; Steve Donovan
>
>                 On Dec 10, 2013, at 12:34 AM, Ben Campbell <[email-masked]> <mailto:[email-masked]> wrote:
>
>                  
>
>                      
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 16 Dec 2013 15:42:02 +0000

Steve,

> The issue with considering only the last report is that it introduces the potential for thrashing between different values.  This could make the overload event even worse.
I am not sure about this. The two agents are not synchronized only for a very small window of time. But even then their reports should be reflecting the status of the realm, approximately if not accurately.
So I don't think using one of the reports will make the situation worse.

I did not understand your argument regarding the security.
The client does not know the agent's identity anyway. So adding agent's identity in the overload-report is not going to change the security consideration anyway.

Regards,
Nirav.

Sent: Monday, December 16, 2013 5:47 PM

Nirav,

The issue with considering only the last report is that it introduces the potential for thrashing between different values.  This could make the overload event even worse.

I agree that this should be a rare case.  I still think, however, that we need to have defined behavior.

One other argument for including the sender of the overload report in the report itself is security.  The ability of a bad actor to insert a malicious overload report can be a very effective DOS attack.  I know we have said we aren't addressing security yet but this seems pretty short sighted.  Being able to establish that the identity of the sender of an overload report will be an important part of the security solution.  We should take this step in that direction.

Steve

Regards,
Nirav.

Nirav,

See inline.

Steve

All,

Regards,

Nirav.

-----Original Message-----

To: Steve Donovan

Steve,

Jouni,

- Jouni

Steve

Ulrich,

nor

between

the endpoint assumption.

- Jouni

-----Original Message-----

From: ext Jouni [

]

Cc: Ben Campbell;

 list; Steve Donovan

comments to 4.3

Ulrich,

Jouni,

- Jouni

Ulrich

-----Original Message-----

]

Cc: Ben Campbell;

 list; Steve Donovan

comments to 4.3

Ulrich,

 wrote:

Jouni,

1. I find the texts

and

contradicting.

Can you please clarify.

of Time would nice..)

- Jouni

Ulrich

-----Original Message-----

From: DiME [

To: Ben Campbell;

 list; Steve Donovan

OVLI: comments to 4.3

Sections 4.1 and 4.3.

          // newsn >= oldsn

          return true;

      } else

          return false;

      }

  }

- Jouni

 wrote:

 wrote:

Jouni,

Steve

Folks

in the -01.

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Mon, 16 Dec 2013 10:09:26 -0600

Nirav,

Assume that there are multiple agents reporting on realm overload.  The
method these agents use to determine realm overload is an implementation
decision, but will require some form of exchange of state between the
agents to keep them in sync.  Note that we can't assume that all agents
are getting all host overload reports.

Under normal circumstances, the difference between the overload reports
from these agents should be small, as you assert. 

But consider the case where the replication mechanism between the agents
is either congested or the network used by the agents to exchange state
is no longer available.  It is easy to construct scenarios in this
situation where agents could be reporting widely different realm
overload report values.

This is clearly an unlikely event, but it is one that can easily be
prevented by including the id of the node that sends a report as part of
the report.

Regards,

Steve

On 12/16/13 9:42 AM, Nirav Salot (nsalot) wrote:
> I am not sure about this. The two agents are not synchronized only for
> a very small window of time. But even then their reports should be
> reflecting the status of the realm, approximately if not accurately.
>
> The client does not know the agent's identity anyway. So adding
> agent's identity in the overload-report is not going to change the
> security consideration anyway.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *Sent:* Monday, December 16, 2013 5:47 PM
> malicious overload report can be a very effective DOS attack.  I know
> we have said we aren't addressing security yet but this seems pretty
> short sighted.  Being able to establish that the identity of the
> sender of an overload report will be an important part of the security
> solution.  We should take this step in that direction.
>
> Steve
>
>     during a small window when synchronization has not taken place
>     between the geographically distributed agents.
>
>     Right?
>
>      
>
>     One proposal for how we deal with the fact that different reports
>     can have different values is to have the reacting node treat the
>     first reporting node as the authority for reporting realm overload
>     state for that overload instance.
>
>      
>
>     i.e. I can understand to define some behavior for the reacting
>     node to handle the case (which is anyway rare case) when two
>     agents provide different realm-report for the same report.
>
>     The behavior could be simply to consider only the last report when
>     two agents have sent two different reports of the same realm. (And
>     this will also work when the same agent has sent two different
>     *Cc:* Ben Campbell; [email-masked] <mailto:[email-masked]> list
>     distributed elements.  In very large networks, this distribution
>     can span continents.  There will be a lag in the "synchronization"
>     of the realm overload information.
>
>     My concern is that we have well defined behavior for when a
>     reactor receives conflicting realm reports.  We need to avoid
>     thrashing between different reduction levels, which could make the
>     overload situation worse.
>
>
>      
>
>     Adding the endpoint identity is needed to allow the reacting node
>     to know that it is receiving two different views of Realm overload
>     from two different reporting end-points.
>
>
>      
>
>     One proposal for how we deal with the fact that different reports
>     can have different values is to have the reacting node treat the
>     first reporting node as the authority for reporting realm overload
>     state for that overload instance.  In this case, the reacting node
>     would ignore reports received from other reporting nodes. In order
>     to ignore reports from non authoritative endpoints requires the
>     reacting node to know which endpoints send which reports.
>
>
>      
>
>      
>
>     Regards,
>
>     Nirav.
>
>      
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 16 Dec 2013 16:26:11 +0000

Steve,

You are talking about "what if one of the agents in the realm has very skewed view of the state of the realm - for whatever reason".
I guess this is much bigger issue and will lead to bigger problems, e.g. all the clients connected to this agent and not sending any request via other agents of the realm, will always have skewed view of the realm.
So that problem should be solved, first. (of course, not here, not by us).

In general, for realm report to be usable, we need to assume that agents are synchronized (except for a very small window of time) and have consistent view (if not exactly the same view always) of the same realm.
Otherwise, realm report will itself create issues among different clients and hence should be avoided completely.

Regards,
Nirav.

Sent: Monday, December 16, 2013 9:39 PM

Nirav,

Assume that there are multiple agents reporting on realm overload.  The method these agents use to determine realm overload is an implementation decision, but will require some form of exchange of state between the agents to keep them in sync.  Note that we can't assume that all agents are getting all host overload reports.

Under normal circumstances, the difference between the overload reports from these agents should be small, as you assert.

But consider the case where the replication mechanism between the agents is either congested or the network used by the agents to exchange state is no longer available.  It is easy to construct scenarios in this situation where agents could be reporting widely different realm overload report values.

This is clearly an unlikely event, but it is one that can easily be prevented by including the id of the node that sends a report as part of the report.

Regards,

Steve

Regards,
Nirav.

Nirav,

Steve

Regards,
Nirav.

Nirav,

See inline.

Steve

All,

Regards,

Nirav.

-----Original Message-----

To: Steve Donovan

Steve,

Jouni,

- Jouni

Steve

Ulrich,

nor

between

the endpoint assumption.

- Jouni

-----Original Message-----

From: ext Jouni [

]

Cc: Ben Campbell;

 list; Steve Donovan

comments to 4.3

Ulrich,

Jouni,

- Jouni

Ulrich

-----Original Message-----

]

Cc: Ben Campbell;

 list; Steve Donovan

comments to 4.3

Ulrich,

 wrote:

Jouni,

1. I find the texts

and

contradicting.

Can you please clarify.

of Time would nice..)

- Jouni

Ulrich

-----Original Message-----

From: DiME [

To: Ben Campbell;

 list; Steve Donovan

OVLI: comments to 4.3

Sections 4.1 and 4.3.

          // newsn >= oldsn

          return true;

      } else

          return false;

      }

  }

- Jouni

 wrote:

 wrote:

Jouni,

Steve

Folks

in the -01.

- Jouni

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list