Subject: RE: [seamoby] Some proposed changes to the requirements draft.

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Nov 2001 16:14:27 -0500

Sharif:
-----Original Message-----
From: Shahrier, Sharif M. [mailto:[email-masked]]
Sent: November 13, 2001 11:29
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]'; Shahrier,
Sharif M.; [email-masked]
Subject: RE: [seamoby] Some proposed changes to the requirements draft.

Gary,
> 
> > 4.16 "The context transfer protocol MUST be scalable. It MUST be 
> > scalable to millions of hosts". 
> 
> This is 'motherhood & apple pie' text (i.e. - noone would really 
> disagree). I don't know how this adds anything to the text.  
> Additionally, I would suggest SHOULD rather than MUST is 
> what you mean. 
> 
Myself, I do not know what "scaleable to millions of hosts" 
really means. If the concern is in regards to the ability for the context 
transfer solution to support a real wireless mobile network and one of the 
constraining factors is the number of ct's that can be handled per time
period, 
then both the number of terminals *and* the number of handoffs per time
period 
are at issue (is trivial to say that any ct solution can handle an infinite
number 
of terminals if the handoff rate is zero
I agree with this. Number of ct's handled per time period and the number of
handoffs per time
Period are both good cases to support the scalability requirement. The other
point is the quantity of context information
Being transferred for each mobile over a given time. This bandwidth must be
scalable.
 It is not clear to me how we would define the scaleability of ct in any
real 
terms. We know that it must be applicable to within an administrative
domain, 
and thus, the top limit would be the IP address space, but that is a
greatest 
upper bound and not very useful. Usually, in these situations, people resort

to rate of complexity measures to define scaleability. 
I agree that the scalability of the CT must be applicabile within an
administrative domain; scalability must also
Be applicable across different operator networks as well.
I don't see how the IPv4 address space affects the scalability of CT. Could
you please explain?
[gwk] I doesn't, other then it puts "a" limit on the possible number of
mobiles within an 
administrative domain. An very high limit. Even higher if the domain uses
IPv6. 
 Finally, scaleability is desireable, as long as the requirement is for
scaleability 
at an acceptable cost. 
 Other then this, I do not know how one would word a requirement around
scaleability 
other then the motherhood of "ct must be scaleable at an acceptable cost". 
I agree. Perhaps something like:
4.16 The context transfer protocol MUST be scalable at an acceptable cost.
        The context transfer protocol MUST be ale to handle a large number
of  of context transfers per second, and MUST
        Be able to support a large number of handoffs per second. The
quantity of context information being transferred for each 
        Mobile per second MUST be scalable, i.e. the bandwidth of the
context transfer MUST be scalable.
        The context transfers MAY be within the same administrative domain,
or they MAY be across different 
         administrative domains. 
[gwk] This is actually 7 requirements. And, there is no way to ensure
conformance to  a number of them
as written. While there are requirements in the existing draft that will be
difficult to ensure conformance, the wg
has made an effort to stay away from requirements which could not be tested
(e.g. there is no "ct must be fast"
requirement). 
My personal opinion is in line with what John stated, that scalability is a
given. Arguably, many stated requirements
are "givens", but are stated for reinforcement. On the other hand, many
givens are not stated as requirements simply to
keep the number of requirements and the scope of the document to a
manageable level. I would put "saleability" in
the latter category, particularly with all the caveats that must go along
with any saleability requirement for ct.
I hope this helps.
Gary

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 13 Nov 2001 13:38:29 -0800

Gary, Sharif, John,

if the requirement is a given, then let's not argue about/against it. It
cannot
hurt to include it, and _technically_ there is consensus for it.

As far as how to phrase it, usually scalability is described as the
marginal increase
in complexity induced by adding users. So something along the lines:
the processing complexity at each AR (and the burden on the wired
network)
SHOULD increase linearly with the number of MNs or the number of CT
requests.

Also, you can check conformance there.

Cedric.

Gary Kenward wrote:

>      From: Shahrier, Sharif M.
>      [mailto:[email-masked]]
>      To: Kenward, Gary [WDLN2:AN10:EXCH];
>      [email-masked]'; Shahrier, Sharif M.;
>      [email-masked]
>      constraining factors is the number of ct's that can be
>      handled per time period,
>      then both the number of terminals *and* the number of
>      handoffs per time period
>      are at issue (is trivial to say that any ct solution can
>      handle an infinite number
>      I agree with this. Number of ct’s handled per time period
>      and the number of handoffs per time
>
>      Period are both good cases to support the scalability
>      requirement. The other point is the quantity of context
>      information
>
>      Being transferred for each mobile over a given time. This
>      bandwidth must be scalable.
>
>      It is not clear to me how we would define the scaleability
>      of ct in any real
>      terms. We know that it must be applicable to within an
>      administrative domain,
>      and thus, the top limit would be the IP address space, but
>      that is a greatest
>      I agree that the scalability of the CT must be applicabile
>      within an administrative domain; scalability must also
>
>      I don’t see how the IPv4 address space affects the
>      scalability of CT. Could you please explain?
>      [gwk] I doesn't, other then it puts "a" limit on the
>      possible number of mobiles within an
>      administrative domain. An very high limit. Even higher if
>      the domain uses IPv6.
>
>      Finally, scaleability is desireable, as long as the
>      requirement is for scaleability
>      at an acceptable cost.
>
>      Other then this, I do not know how one would word a
>      requirement around scaleability
>      The context transfer protocol MUST be ale to handle a large
>      number of of context transfers per second, and MUST
>
>      Be able to support a large number of handoffs per second.
>      The quantity of context information being transferred for
>      each
>
>      Mobile per second MUST be scalable, i.e. the bandwidth of
>      the context transfer MUST be scalable.
>
>      The context transfers MAY be within the same administrative
>      domain, or they MAY be across different
>
>      administrative domains.
>      [gwk] This is actually 7 requirements. And, there is no way
>      to ensure conformance to  a number of them
>      as written. While there are requirements in the existing
>      draft that will be difficult to ensure conformance, the wg
>      has made an effort to stay away from requirements which
>      could not be tested (e.g. there is no "ct must be fast"
>      requirement).
>
>      My personal opinion is in line with what John stated, that
>      scalability is a given. Arguably, many stated requirements
>      are "givens", but are stated for reinforcement. On the other
>      hand, many givens are not stated as requirements simply to
>      keep the number of requirements and the scope of the
>      document to a manageable level. I would put "saleability" in
>
>      the latter category, particularly with all the caveats that
>      must go along with any saleability requirement for ct.
>
>      I hope this helps.
>      Gary
>

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 14 Nov 2001 08:34:16 +0100

No, it is not a given that there's a requirement that the protocol MUST be
scalable to millions
of hosts. It SHOULD be scalable to the number of hosts that a MN may
reasonably have as
candidate access routers for a handover. And I believe that's reasonably
well covered in the
draft, even if it's not explicit and by numbers.

 And no, we MUST NOT have an extensive discussion about the formulation of
this point.
 I think, from the start we've been over this a number of times; so to put
it bluntly, have those
that advocate changes to the draft now have a tangible project with a need
for this protocol,
which would NOT be catered to with the current requirements - if we can ever
get this thing to fly?

The matter of authentication was up earlier; now consider this: If you
require strong mutual
authentication and scalability to a MILLIONS of hosts, you are talking about
MILLIONS
SQUARED number of pairwise security associations. To no tangible use. Until
we get teleportation,
that is, and can go to the neighbourhood of any access router on the earth
instantly.

Please, can we drop this?

    Henrik

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Cedric Westphal
  Sent: Tuesday, November 13, 2001 10:38 PM
  To: Gary Kenward
  Cc: 'Shahrier, Sharif M.'; [email-masked]
  Subject: Re: [seamoby] Some proposed changes to the requirements draft.

  Gary, Sharif, John,

  As far as how to phrase it, usually scalability is described as the
marginal increase
  in complexity induced by adding users. So something along the lines:
  the processing complexity at each AR (and the burden on the wired network)
  SHOULD increase linearly with the number of MNs or the number of CT
requests.

  Cedric.

  Gary Kenward wrote:

    Sharif:
      -----Original Message-----
      From: Shahrier, Sharif M. [mailto:[email-masked]]
      Sent: November 13, 2001 11:29
      To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
Shahrier, Sharif M.; [email-masked]
      Subject: RE: [seamoby] Some proposed changes to the requirements
draft.

      Gary,

      Myself, I do not know what "scaleable to millions of hosts"
      really means. If the concern is in regards to the ability for the
context
      transfer solution to support a real wireless mobile network and one of
the
      constraining factors is the number of ct's that can be handled per
time period,
      then both the number of terminals *and* the number of handoffs per
time period
      are at issue (is trivial to say that any ct solution can handle an
infinite number
      of terminals if the handoff rate is zero

      I agree with this. Number of ct’s handled per time period and the
number of handoffs per time

      Period are both good cases to support the scalability requirement. The
other point is the quantity of context information

      Being transferred for each mobile over a given time. This bandwidth
must be scalable.

      It is not clear to me how we would define the scaleability of ct in
any real
      terms. We know that it must be applicable to within an administrative
domain,
      and thus, the top limit would be the IP address space, but that is a
greatest
      upper bound and not very useful. Usually, in these situations, people
resort
      to rate of complexity measures to define scaleability.

      I don’t see how the IPv4 address space affects the scalability of CT.
Could you please explain?
      [gwk] I doesn't, other then it puts "a" limit on the possible number
of mobiles within an
      administrative domain. An very high limit. Even higher if the domain
uses IPv6.

      Other then this, I do not know how one would word a requirement around
scaleability
      other then the motherhood of "ct must be scaleable at an acceptable
cost".

      4.16 The context transfer protocol MUST be scalable at an acceptable
cost.

      The context transfer protocol MUST be ale to handle a large number of
of context transfers per second, and MUST

      Be able to support a large number of handoffs per second. The quantity
of context information being transferred for each

      Mobile per second MUST be scalable, i.e. the bandwidth of the context
transfer MUST be scalable.

      The context transfers MAY be within the same administrative domain, or
they MAY be across different

      administrative domains.
      [gwk] This is actually 7 requirements. And, there is no way to ensure
conformance to  a number of them
      as written. While there are requirements in the existing draft that
will be difficult to ensure conformance, the wg
      has made an effort to stay away from requirements which could not be
tested (e.g. there is no "ct must be fast"
      requirement).

      My personal opinion is in line with what John stated, that scalability
is a given. Arguably, many stated requirements
      are "givens", but are stated for reinforcement. On the other hand,
many givens are not stated as requirements simply to
      keep the number of requirements and the scope of the document to a
manageable level. I would put "saleability" in
      the latter category, particularly with all the caveats that must go
along with any saleability requirement for ct.

      I hope this helps.
      Gary