Subject: [seamoby] Comments on draft-koodli-seamoby-ctv6-00.txt

From: James Kempf <[email-masked]>
Date: Thu, 12 Jul 2001 13:47:52 -0700 (PDT)

Hi Rajeev,

I looked over your draft and I have some comments.

1) pg. 5 I like your charaterization of GTP (not the other one) but the
idea that it consists of a type identifier and *state* variables
brings up a fundamental question w.r.t. context transfer. Protocols
usually define the interface between two different network elements.
State variables have to do with implementation. Isn't context
transfer basically asking for implementations to be exposed?

For example, suppose I am SuperWhizzy QoS Router manufacturer and
I have a router that supports the Diffserv  protocols just fine,
so it interoperates, but inside I have my proprietary algorithms
that make my router live up to its name. In order to provide state
transfer, would I need to expose the internals of my algorithms
so I could interoperate?

I'm not sure how to solve this problem, but I think you need to
clarify that these state variables aren't internals of the implementation,
but rather protocol-specified state variables that are part of the
interface.

2) pg. 5 What is the filter and handle alluded to in the last paragraph?
There is not alot of detail as to what these are supposed to do.

3) pg. 7 and the whole discussion of SHIN/SHAK header options. When
I first read this, I thought these were being defined for the purpose
of having the MN do context transfer to the router, which didn't make
any sense to me. After I got to Section 5, however, it became clear
that what you really mean is that the MN signals to the router that
it wants particular context to be transfered. I think you need to
rewrite it to make this clear (but see below for some comments on
the utility of the SHIN/SHAK in the first place).

4) Section 4.3-4.5 I like the idea of the context transfer being an
extension to the HO messaging. Reduces the number of timers required
in the router. And it is possible in IPv6. The only issue here is
there has been some opinion expressed on the list that a reliable
transport might be a better idea for context transfer, which would
not be possible with ICMP extensions.

5) pg. 12 - What happens if a router or MN asks for some context to
be transfered and it is not available?

6) pg 12 - What is an unsolicited SHREP? Up until this point, I don't
think it has been described. You may want to describe it in the
terminology section, or somehow earlier in the paper.

7) pg. 13 Section 5.1 Actually, I think this scenario is pretty
unlikely for slow speed links, or, if it occurs at all, it will probably occur 
when there is almost no traffic between the MN and the network. I think
that any scenario where the MN has to trigger the context transfer
is not likely to occur when there is active traffic because it will involve
messaging over the wireless link, which is the slowest. 

I think it more likely that context transfer occurs as part of the HI/HACK
as described in Section 5.2. I don't think the MN needs to signal over
the air to get the CT to happen (P-SHIN), I think that CT could be 
triggered by the need for a handover. The L2 triggers draft, which
should be out shortly, spells out requirements for L2 triggers to
support CT.

With faster wireless protocols, the over-the-air signaling won't have
as much cost (but it will always have a higher cost than over the wire),
so the option should probably be kept in, but I think for standard
3G scenarios, triggering the context transfer as part of the need
for a handover without any over-the-air signalling is likely to be
much faster.

		jak

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 13 Jul 2001 13:02:25 -0700

Actually, I have another comment. Figure 2, and the surrounding text,
implies that each blob is targetted for a particular flow. However,
what about state info that isn't flow specific? An example is some AAA
information, which is "session based". Is that what the top "context"
box implies? You may want to consider this in your next revision.

PatC