Subject: [NSIS] GIMPS scalability

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Tue, 24 Feb 2004 10:18:50 +0100

Hi Henning and Robert,

I have some comment regarding scalability. In GIMPS draft there is a scalabiliy statement:

'' Scaleable: As will be discussed in Section 4.3, up to one messaging
association is generally kept for each adjacent GIMPS peer and
thus association state scales better than the number of sessions.
(Many peers may not have association state at all, if there are no
messages on sessions visiting those nodes that warrant such
treatment.) Messaging associations are managed based on policy at
each node, depending on trade-offs between fast peer-to-peer
communication and state overhead. Messaging association state can
be removed immediately after the last signaling session to a
particular next-hop is removed, after some delay to wait for new
sessions or only if resource demands warrant it.'' 

It is clear that association state scales better than number of sessions because usually an associacion is used by more sessions. However, routing states are per-flow e.g. scales with number of flows, which can be an issue. Furthermore, I do not see support for aggregation in the description. 

Best regards, Attila

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Feb 2004 10:13:41 -0000

hi attila,

you are quite right that the routing state scales as the
number of flows.

however, i think this is fundamentally an unavoidable
consequence of wanting to do per-flow signalling. all that
we can do in GIMPS is to ensure that routing state only
needs to be kept when absolutely necessary, i.e. to allow
the cases where routing state does not need to be kept to
be handled efficiently. 

so far, we've identified two such cases:

a) sending downstream signalling without requiring routing
state to be installed. this is possible with GIMPS (maybe
it needs to be made more clear) if the signalling application
so requests.

b) protecting the network from per-[micro]-flow signalling
when those flows are being handled inside an aggregate. 
two ways are possible: setting the RAO so datagram messages
are ignored and then C-mode signalling runs edge-to-edge
only and is not interpreted between the edges; and putting
the microflows and their signalling inside a tunnel (so they
are invisible).

In addition, the current Flow-Routing-Information allows a 
limited degree of wildcarding (leaving some protocol fields
unspecified) so you don't have to store identical routing state
for large numbers of nearly identical flows. 

We're open to additional suggestions about how to minimise
per-flow state requirements!

I am not sure whether you are asking for more description
of aggregation in the GIMPS specification, and if so, where.
My view is that aggregation itself is a signalling application
function; all that GIMPS can do is enable the micro signalling
to be ignored where appropriate. This is basically (b), where
the information is already contained in the draft - but if
you think it could be better arranged or expressed, please
let me know.

cheers,

robert h.

> -----Original Message-----
> From: Attila Báder (IJ/ETH) [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2004 10:19
> To: 'nsis'; Henning Schulzrinne; Hancock, Robert
> Subject: GIMPS scalability
> 
> 
> Hi Henning and Robert,
> 
> It is clear that association state scales better than number 
> of sessions because usually an associacion is used by more 
> sessions. However, routing states are per-flow e.g. scales 
> with number of flows, which can be an issue. Furthermore, I 
> do not see support for aggregation in the description. 
> 
> Best regards, Attila

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Tue, 24 Feb 2004 12:49:24 +0100

Hi Robert,

Thank you very much for the clarification. The reason I raised this question is that many times scalability, i.e. storing per-flow routing and reservation states, is mentioned as one of the main arguments against using RSVP. RSVP aggregation targeted this problem and it is addressed in main places in QoS NSLP draft, as well as in our RMD-QoS-model draft. I think, it would be useful if it is pointed out also in NTLP how it is supported in that layer. Though, I see that the necessary elements are included in the description, a summary, like in your answer, would be useful, e.g. in 3.2 under Scalability.

Best regards, Attila

> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2004 11:14 AM
> To: Attila Báder (IJ/ETH); 'nsis'; Henning Schulzrinne
> Subject: RE: GIMPS scalability
> 
> 
> hi attila,
> 
> -- 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>