Subject: RE: [seamoby] Question on CT req 4.9

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 19 Jun 2001 20:47:23 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 8:25 PM
> To: [email-masked]
> Subject: [seamoby] Question on CT req 4.9
> 
> 
> This require appears to imply that a context transfer is a 
> one-shot event. The whole
> enchalada is sent when handoff occurs. Although I tend to 
> agree with this, I would
> claim that in my mind (at least) it seems feasible for high 
> priority data to be
> collected and transferred (e.g. HC state), while lower 
> priority data be sent 
> a few seconds later (e.g. AAA accounting information). 
> 
> The reason why perhaps this may be useful is that if the 
> packet size, and hence
> context state, of the high priority data is small enough, it 
> will be faster to
> build on the oAR, parse, and install on nAR.

I would think this makes sense.  The desire would be that high priority data
fit in the MTU for low latency transfers.  While the rest can be sent in the
next packet, to reduce the timing/bandwidth constraints on the overall
operation.  

Initially, the possible types of context may be limited, but over time as
new context types are defined for new protocols, we may exceed MTU.  Also,
MTU may vary across implementations/access technology types. 

- Kulwinder.

> 
> Has this discussion already taken place? Was there a decision 
> that was taken?
> 
> Thanks,
> 
> PatC 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 20 Jun 2001 10:24:22 -0400

This is a really soft requirement Pat. It is really an embodiment of what 
was considered a simplifying assumption - namely, that if the context was
available, there would be no requirement to build a multi-phasic protocol.

You give a valid argument a phased context transfer. However, in order to 
defined this properly, we would have to build in mechanisms to inform the
receiving AR when the full context had indeed been received. In addition,
there was a concern (I think it was shared by more then me, but I can never
be sure any more), that there may be an ordering/sychronization/latency
issue for a phased transfer - i.e. can we be sure that the context that
arrives later will always work with the context that arrived earlier? How
can we be sure. For example, I send the QoS, compression, etc. state for a
flow first, and the authorization second, however, in between the microflow
is discontinued.

Just some thoughts. Don't care either way if it is in or out. A good
implementation will address these issues if the protocol does not.

Gary

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 20 Jun 2001 15:46:56 -0400

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 10:24 AM
To: 'Pat Calhoun'; [email-masked]
Subject: RE: [seamoby] Question on CT req 4.9

There is also a implementation specific design assumption here that all
technologies will have the same or sufficient bandwith/MTU/CPU cycles
available to do a complete CT in real-time.  This is not the case. 

This could be a single bit set in the header.

- Kulwinder. 

Gary 

> From: Pat Calhoun [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 20 Jun 2001 16:53:10 -0400

Kulwinder:

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 3:47 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'; [email-masked]
Subject: RE: [seamoby] Question on CT req 4.9

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 10:24 AM
To: 'Pat Calhoun'; [email-masked]
Subject: RE: [seamoby] Question on CT req 4.9

I guess, given the precept that CT was to enhance the real-time performance
of handover, it would seem a reasonable assumption that the ARs could
perform in real time. 

There seems to be an emerging them of performing a reactive context transfer
in stages, the first stage providing enough context to allow one or more
packets to be forwarded so that the the added delay is kept as small as
possible, the latter stage providing the remaining context. I have my doubts
about this approach, but I do see the value in extending the definition of
reactive ct to allow for it.

The essential difference between the existing requirement and this modified
approach is to ensure that the first packet arrival (or arrivals) are not
buffered waiting for the ct to complete.

May I suggest that the way to address this is to modify the definition of
reactive so that it allows ct to complete after the packet forwarding
commences?

And what happens if that packet is lost? There needs to be recovery
mechanisms built in, etc., etc. The point is that there is an additional
mechanism required (and it's never as simple as a "single bit in the
header"). 

Having said this, the case for splitting ct for reactive mode has been made,
so I guess we will have to find a solution ;^}.

- Kulwinder.  

Gary 

Gary

---

From: [email-masked]
Date: Thu, 21 Jun 2001 09:33:30 +0300

Hi Pat

> a few seconds later (e.g. AAA accounting information). 

I agree with you.  I think 4.9 should be rewritten so that
the whole enchalada can be sent at once, but does not have 
to be.

br,
John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 21 Jun 2001 12:24:13 -0500

I like this idea.

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 1:34 AM
To: [email-masked]; [email-masked]
Subject: RE: [seamoby] Question on CT req 4.9

Hi Pat

br,
John