Subject: RE: [seamoby] CT requirements

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 14 Nov 2001 18:04:05 -0600

I second James opinion. 
Furthermore what is referred to as "data integrity" is covered
as reliability in the existing requirement doc (see 4.13).
Maybe it needs to be spelled out??

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 5:11 PM
To: Shahrier, Sharif M.; [email-masked]
Subject: Re: [seamoby] CT requirements

With the exception of 5.6.1, I am opposed to the other requirements.

        jak

----- Original Message -----
From: "Shahrier, Sharif M." <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 14, 2001 1:28 PM
Subject: [seamoby] CT requirements

> Everyone:
>
> There hasn't been any "consensus" against the requirements that I'm
> indicating below. There had been a couple of comments, to which I
responded,
> but I did not get anything back.
>
> I would like to point them out again, and if there is no real WG
consensus
> against them, I see no reason why they should not be in the CT
requirements
> draft.
>
> 5.5.2 A context update MUST preserve the integrity, and thus the
meaning, of
> the context at each receiving AR.
>
>    The context at the AR actually supporting an MN's traffic will
change
> with time. For example, the MN may initiate new microflow(s),
>    or discontinue existing microflows. Any change of context at the
> supporting AR must be replicated at those ARs that have already
>    received context for that MN.
>
>    I don't see what the paragraph above has to do with data integrity,
and
> thus I recommend that it should be rewritten or removed altogether.
Unless I
> am wrong, I had thought that data integrity refers to the
"correctness" of
> data.
>
> 4.17 "The context transfer protocol MUST minimize the number of
>        signaling messages at the sending and receiving Access
Routers".
>
>
> Minimizing signaling messages have several benefits: (a) reduces load
on the
> Internet by signaling messages, (b) increases the bandwidth afforded
to data
> traffic, (c) improves the effective utilization of data traffic, (d)
> improves reliability, (e) improves scalability.
>
> I've seen one comment on this, but did not get a response after I
replied.
>
> Now, the centralized/local context storage caused some issues. Thus, I
would
> like to re-word it and hope that it would be more acceptable.
>
> The context transfer protocol MUST support localized storage of
context at
> the ARs.
>
> The context transfer protocol MAY also support a centralized storage
of
> context belonging to  the ARs in the sub-net.
>
> I think that keeping a "back up" of context information in a central
> directory will help will fault-tolerence, i.e. reliability, and it
provides
> consistency with some of the current implementations in wireless
networks.
> It also broadens the solution space ............
>
> 5.6.1 "The context transfer protocol MUST include methods for
interworking
> with any IETF IP handover solutions".
>
> The IETF have several handover solutions, and unless the objective is
to
> come up with a different context transfer solution to fit a specific
> handover protocol, it should make sense to include this requirement.
>
> Personally, I think it is good practice to have a single CT solution
and
> design it for the worst-case.
>
>
> -Sharif.
>

---

From: [email-masked]
Date: Thu, 15 Nov 2001 08:39:39 +0200

Hi James,

> With the exception of 5.6.1, I am opposed to the other requirements.

I agree with James.  5.6.1 is OK, the others I oppose.

John

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 15 Nov 2001 10:20:30 -0500

Sharif:

> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: November 14, 2001 16:29
> To: [email-masked]'

*snip*

> 
> 5.5.2 A context update MUST preserve the integrity, and thus 
> the meaning, of
>    The context at the AR actually supporting an MN's traffic 
> will change
>    I don't see what the paragraph above has to do with data 
> integrity, and
> thus I recommend that it should be rewritten or removed 
> altogether. Unless I

Define correctness. Then maybe you will understand the meaning
of the paragraph.

> Minimizing signaling messages have several benefits: (a) 
> reduces load on the
> Internet by signaling messages, (b) increases the bandwidth 
> afforded to data
> I've seen one comment on this, but did not get a response 
> after I replied.

I have no idea what you are proposing here. More words? Is the change
really necessary, or does everyone already understand what the requirement
means and what the benefits are?

> 
> Now, the centralized/local context storage caused some 
> issues. Thus, I would

Not really. The discussions at the beginning of the
year explicitly ruled out a centralized repository or server
approach to ct. There was (as far as I recall) very little support
for a "ct server" type of approach. The preference was for ct to 
be peer to peer.

> 
> The context transfer protocol MUST support localized storage 
> of context at
> the ARs.
> 
> The context transfer protocol MAY also support a centralized 
> storage of
> directory will help will fault-tolerence, i.e. reliability, 
> and it provides
> consistency with some of the current implementations in 
> wireless networks.

It also has absolutely nothing to do with seamlessness. Which is 
why we are here. CT is not about maintaining RABs, etc. it is about
quickly and efficiently re-creating the forwarding support for an
MNs traffic at a new AR. 

> The IETF have several handover solutions, and unless the 
> objective is to

The requirement for interworking with mobility solutions encompasses
handover.
I realize that over the years people have built up specific connotations of
mobility and handover, but in *english*, mobility means the MN is mobile.

Said in a different manner, if interpretation is that the requirements state
that ct will work with any IETF *mobility* solution but only one *handover*
solution.
Pretty bizarre, don't you think?

> 
> Personally, I think it is good practice to have a single CT 
> solution and

The worse case might be AMPs. Or how about mobile radio telephony service.

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 15 Nov 2001 10:27:40 -0500

To clarify my previous comment, 5.6.1 is also "ok" in my view, just
not necessary.

gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: November 15, 2001 01:40
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby] CT requirements
> 
> 
> Hi James,
>