Subject: [NSIS] 5.5.4 requirement (Section 5.5.4)

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 14:05:35 +0100

Hi Marcus

Regarding requirement:
"Aggregation method specification"
used in Section 5.5.4

I do not know if any initiator will be able to define an aggregation method.
An edge node of a domain can do it, but an end host can in my opinion not do
it. 
Thus I do not know how to interpret this requirement!

Best regards,
Georgios

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

---

From: Winter Martin <[email-masked]>
Date: Fri, 8 Mar 2002 14:53:18 +0100

Hi Georgios,

I support your view. An initiator is not able to exactly know the impact of aggregation on his QoS, so he also cannot specify an aggregation method. What an initiator wants, is not a specific aggregation method, but just a service. It does not matter, how it is realised. 

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 2:06 PM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: [NSIS] 5.5.4 requirement (Section 5.5.4)
> 
> 
> Hi Marcus
> 
> Regarding requirement:

-- 
Martin Winter
AQUILA Project http://www.ist-aquila.org
------------------------------------------------------
 Siemens AG         Voice: +49 89 722-63718
 ICN WN CC NA A19   Fax:   +49 89 722-41920
 Hofmannstr. 51     Mail:  [email-masked]
 81359 Muenchen
 Germany

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Mar 2002 15:10:45 +0100

Hi Martin, Georgios,

I agree too, an end system can't specify how to aggregate. A domain accepting a reservation is committing itself to provide the requested service. It doesn't matter to the end system how this is done.

Regards, Rüdiger

> I support your view. An initiator is not able to exactly know 
> the impact of aggregation on his QoS, so he also cannot 
> specify an aggregation method. What an initiator wants, is 
> not a specific aggregation method, but just a service. It 
> does not matter, how it is realised. 
> 

> > An edge node of a domain can do it, but an end host can in my 
> > opinion not do it.

---

From: [email-masked]
Date: Fri, 8 Mar 2002 15:57:28 +0100

Hi all,

I agree as well. I even think the end-user doesn't really care, as long as
he gets the requested service (whether he is aggregated with others or
not).

Just my 2cc,
Sven

"Geib, Ruediger" <[email-masked]> on 08/03/2002 15:10:45

  To:          [email-masked]                   
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

  Subject      RE: [NSIS] 5.5.4 requirement (Section 5.5.4)   
  :                                                           

Hi Martin, Georgios,

I agree too, an end system can't specify how to aggregate. A domain
accepting a reservation is committing itself to provide the requested
service. It doesn't matter to the end system how this is done.

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Mar 2002 19:47:34 -0000

hi all,

i suspect i have to own up to originating this requirement.

my (possibly rather feeble) background thinking was that the user's original reservation can be accepted in some absolute sense.
however, when the flow gets thrown in with an aggregate, the original QoS is probably only guaranteed in some statistical sense. therefore, while the user doesn't care about *how* the aggregation is done, he might have some views about the *strength* of the statistical guarantee that was desired (in other words, how aggressively it is reasonable to aggregate his flows.)

but maybe the original reservation is also generally admitted statistically, and maybe statistical issues are part of service definition (a.k.a. the 'section 3.5' thread) and therefore out of NSIS signalling scope anyway.

i'm not wedded to it, in any case.

r.

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 08 March 2002 14:57
> To: Geib, Ruediger
> Cc: [email-masked]; [email-masked]
> Subject: RE: [NSIS] 5.5.4 requirement (Section 5.5.4)
> 
> 
> Hi all,
>

---

From: [email-masked]
Date: Mon, 11 Mar 2002 09:18:23 +0200

Hi Robert,

> my (possibly rather feeble) background thinking was that the 
> user's original reservation can be accepted in some absolute sense.
> however, when the flow gets thrown in with an aggregate, the 
> original QoS is probably only guaranteed in some statistical 
> sense. therefore, while the user doesn't care about *how* the 
> aggregation is done, he might have some views about the 
> *strength* of the statistical guarantee that was desired (in 
> other words, how aggressively it is reasonable to aggregate 
> his flows.)
> 
> but maybe the original reservation is also generally admitted 
> statistically, and maybe statistical issues are part of 
> service definition (a.k.a. the 'section 3.5' thread) and 
> therefore out of NSIS signalling scope anyway.

I concur - I think that this goes to far down the implementation
/ service definition road to be useful in the general requirements
document - so it should be removed.

Thanks,
John

---

From: [email-masked]
Date: Mon, 11 Mar 2002 10:00:00 +0100

Hi Robert,

I must admit I feel more for your second suggestion. I suspect guarantees
will always come with some statistics attached to them. There may be other
reasons, however, to request that you will not be aggregated with other
flows (security?). If such reasons exist, I think it may be advantageous to
specify whether or not you are aggregated (so just 1 bit).

Regards,
Sven.

"Hancock, Robert" <[email-masked]> on 08/03/2002 20:47:34

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, "Geib,  
               Ruediger" <[email-masked]>        
                                                              
  cc:          [email-masked], [email-masked]    

hi all,

my (possibly rather feeble) background thinking was that the user's
original reservation can be accepted in some absolute sense.
however, when the flow gets thrown in with an aggregate, the original QoS
is probably only guaranteed in some statistical sense. therefore, while the
user doesn't care about *how* the aggregation is done, he might have some
views about the *strength* of the statistical guarantee that was desired
(in other words, how aggressively it is reasonable to aggregate his flows.)

but maybe the original reservation is also generally admitted
statistically, and maybe statistical issues are part of service definition
(a.k.a. the 'section 3.5' thread) and therefore out of NSIS signalling
scope anyway.

r.

> > > Thus I do not know how to interpret this requirement!
(See attached file: RMRL-Disclaimer.txt)

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 11 Mar 2002 10:11:20 +0100

Hello Sven,

> There may be other reasons, however, to request that you
> will not be aggregated with other flows (security?).
> If such reasons exist, I think it may be advantageous to

Could you go into more detail what you mean by security reasons preventing aggregation? Also "secure" ATM/FR cells are multiplexed on transmission systems and switches. I don't think aggregation means much more than multiplexing. 
Or would your understanding of aggregation be something like "set up a container and fill packets belonging to different flows into container & forward container instead of individual packets"? 

Regards, Rüdiger

---

From: [email-masked]
Date: Mon, 11 Mar 2002 10:23:40 +0100

Hi Ruediger,

I am by no means a security specialist. I reacted to the requirement of
'needing to signal aggregation type' because I thought it was both
infeasible and unneeded. But I didn't want to make such a hard statement
because I couldn't assess all possible security risks. Therefore I thought
we could the possibility for a boolean aggregation parameter open. What do
you think?

Sven.

"Geib, Ruediger" <[email-masked]> on 11/03/2002 10:11:20

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:          [email-masked]                                  

Hello Sven,

> specify whether or not you are aggregated (so just 1 bit).

Could you go into more detail what you mean by security reasons preventing
aggregation? Also "secure" ATM/FR cells are multiplexed on transmission
systems and switches. I don't think aggregation means much more than
multiplexing.
Or would your understanding of aggregation be something like "set up a
container and fill packets belonging to different flows into container &
forward container instead of individual packets"?

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 11 Mar 2002 11:27:33 +0100

Hi Sven,

to me end systems telling routers how to aggregate services sounds a bit like active networking. I'm favouring the classic approach that a customer negotiates a service with a provider and leaves it to the provider how that service is realised. If there's a no-aggregation issue, it should be part of the service definition rather than the signalling. In consequence, I don't look at aggregation/no-aggregation as a signaling issue. I don't want to spend the bit.

Regards, Rüdiger

> Sent: Monday, March 11, 2002 10:24 AM
> To: Geib, Ruediger
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 11 Mar 2002 15:41:46 +0100

Hi Rudiger, Sven,

I agree with Rudiger's proposal; we should not forget that when we use the
words "service provider" and "customer" we are talking about a contractual
relation, implying generally some amount of money in between.
So, it is hard to imagine that a customer takes a subscription describing
the provided service and how it is actually implemented in the network.
IMHO, the service provider is free to aggregate (what and at which level),
compress, etc. etc. providing that he is still complying with the service
definition (behaviour, including QoS guarantees), that is, that the
contractual relation with the customer is not violated.

Best regards
Juan Carlos

"Geib, Ruediger" <[email-masked]>@ietf.org on 11/03/2002
11:27:33

Sent by:  [email-masked]

Hi Sven,

to me end systems telling routers how to aggregate services sounds a bit
like active networking. I'm favouring the classic approach that a customer
negotiates a service with a provider and leaves it to the provider how that
service is realised. If there's a no-aggregation issue, it should be part
of the service definition rather than the signalling. In consequence, I
don't look at aggregation/no-aggregation as a signaling issue. I don't want
to spend the bit.

Regards, Rüdiger