Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 1 Aug 2002 11:46:49 -0500

Hi James,

Below is a crack at the transport section, I have tried to accomodate all
parties. Except the use of UDP and Acks, if that is important the following
can be added under X.X.1 (with the risk of opening the Pandora's box :( ) 

	Specific feature context transfers MAY allow the embedding very simple
 	reliability mechanisms such as Acks in conjunction with use of UDP. 
	Care, must be taken to adhere with X.X.2 (not redesign a transport protocol). 

Hope it helps,
Regards,

Madjid
=================start=================================
X.X Context transfer protocol in its generic form MUST be designed independent
of the underlying transport protocol. 

X.X.1 A generic context transfer protocol MUST accommodate scenarios that do not require or can not accept the complexity of all transport protocols. 

X.X.2 Context Transfer MUST allow the use of more complex transport protocols (such as
those providing reliability) for transferring specific features that require complex
transport functionalities. 
The context transfer MUST however avoid introducing redundancy in transport mechanisms
 (such as retransmissions). In other words, in cases, where such functionality can be provided by an underlying standard transport protocol, the context transport protocol
MUST NOT embed such functionalities in its design. Instead the context transfer protocol MUST seek to utilize a "standard" transport protocol instead.
 
	Context transfer protocol design SHOULD employ IETF transport protocols such 
	as SCTP/TCP for such cases. Note that for such protocols, it is advised to 
	perform the association/ session message exchange between context transfer
	 peers (ARs) in anticipation of handovers (if possible) to accomodate
	 transfer of time-critical feature contexts.

I picked part of this one from earlier emails:

X.X.3 A feature context specification MUST define the transport to be used. If
	 the feature context is transferred using an IETF transport layer protocol ,
	 then the feature context specification MUST include the full details of how
	 the transport layer protocol is used.
	However, One must note that employing different transport mechanisms for different
	 feature context might lead to limited possibility of multiplexing various feature
	 contexts. Therefore, such details NEED NOT be included in a generic context transfer
	protocol design.

X.X.4 In case a specific functionality (such as sending updates) is not
	provided by an IETF transport protocol, such functionality MAY be
	added as an OPTIONAL element to the specific feature context transfer
	specification.
===================End =======================================

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 3:15 PM
To: Nakhjiri Madjid-MNAKHJI1; 'Rajeev Koodli'
Cc: [email-masked]
Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Madjid,

Do you have some specific text you would like to propose regarding the
transport?

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 24, 2002 4:20 PM
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

> Rajeev,
>
> sorry for the delay. see below.
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 4:24 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: James Kempf; [email-masked]
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context
> Specifications
>
>
>
> Hello Madjid,
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > - regarding the transport text, if a particular feature indicates UDP/TCP
> > or SCTP, isn't that sufficient ? Even if it can provide more information,
> > how
> > is that going to be useful if it is not supported by the underlying
> > transport
> > protocol ?
> >
> > Madjid>> First of all, not everybody and every feature need an advanced
> > transport and I know we agree on this.
> > However, say in 6 months we are debating an specific feature that does need
> > reliability. This text is to protect us from sloppy design.
> > If you remember Jeff Schiller saying: Don't come and say use
> > IPSec if you want security, you need to work on the security details.
> >
> > Example of a case which even SCTP is not going to cut it (this is
> > answer to your next question as well): say you are sending a very
> > dynamic context (packet count or HC context) and you want reliability
> > (and you got time to resend stuff...).
> > You send the context, but due to do channel conditions don't get it through,
> > next time, you have to send updates. This has to come from the feature unit
> > and not from transport layer. If had just said use SCTP for reliability that
> > would not be a robust design.
> >
>
> When you have to send an update, you do it whether or not SCTP failed to
> get it through in the first case, right ? What SCTP or a reliable transport
> protocol will offer you is the ability to send a message reliably. When you
> have a new message or an update, I agree the feature code has to supply it
> (and SCTP has to get to the destination reliably)!
>
> Madjid>> True, furthermore, if you use a reliable protocol like
> SCTP, you need to take extra care with CT, so the receiver doesn't mix up
> updates from app. layer, with retx from transport.
>
>
> I hope you are not indicating that each feature has to design its own reliable
> transmission protocol. The way each feature uses SCTP or UDP is internal
> to the feature, and is not a function of the CT protocol itself. The
> CT protocol
> should define a set of messages that can be carried over different transport
> protocols.
>
> Madjid>> No, No, however, If we add a set of minimal support (like
> what I mentioned above) to the generic protocol, then provide the option
> for the feature to use it or not we are covered.
> If we completely ignore reliability
> completely, we will write off CT as a useful protocol, I think!
>
> BR,
>
> Madjid
>
> Regards,
>
> -Rajeev
>
>
>

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 1 Aug 2002 11:46:49 -0500

Hi James,

Hope it helps,
Regards,

Madjid

 

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 3:15 PM
To: Nakhjiri Madjid-MNAKHJI1; 'Rajeev Koodli'
Cc: [email-masked]
Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Madjid,

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 24, 2002 4:20 PM
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 9 Aug 2002 12:59:16 -0400

Charlie:

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: August 9, 2002 12:07
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Hello Gary,
> I'd like to represent another viewpoint.

Certainly.

> 
> > Gary Kenward wrote:
> 
> >                                                The main issue is
> > that I see a tendency towards having a different transport for every
> > feature context,
> 
> How about a mapping of feature contexts into a small number of
> transport protocols (e.g., UDP, TCP, SCTP, ICMP)?

May happen. Why make it a requirement, or imply that this is the best
solution within the requirements document? There is a debate to take
place over this issue, and we should have it, when the we start discussing
solutions. But let us not presume that it is part of the solution.

> 
> >                   with potentially different mappings for 
> each combination
> > of context and transport protocol combination.
> 
> Can you be more specific about what you mean here?

If all context is transfer as data chunks in the payload, then there really
isn't
a problem. However, if one starts mapping ct information into option fields
of various
protocols, the mappings will very likely change due to the differences in
protocol
syntax. IPv4 vs. IPv6 seems to be the most pronounced example.

> 
> >          ........                       there would be little to the
> > actual CT protocol except for a specification of the feature context
> > encapsulation format, and possibly the rules for 
> multiplexing multiple
> > feature contexts onto a give transport frame.
> 
> But that would already be quite valuable, from my perspective.

A necessary component of the total solution for CT, but definitely
only part of the answer. The real issue here is whether the CT capability is
fulfilled with a single protocol or a suite of protocols. I believe the
former is
a preferable solution, if the protocol complexity is manageable, which I
believe it
is. 

We have pretty well decided that CT capability involves at least two
protocols (above IP):
a CT containerizing protocol, and a transport protocol. Two is still better
then a gaggle
of protocols, IMHO.

> 
> > Implementation of a collection of protocols, feature CT and 
> each associated
> > transport protocol, would also be problematical.
> 
> If the transport protocols are UDP, TCP, SCTP, and ICMP, there isn't
> much problem with implementation.  Or maybe I missed your point...

Well, this assumes that the ARs have end-point stacks for all of the
transport
protocols, and management interfaces, etc. Most routers have ICMP/UDP
support.
Not sure about TCP, and I doubt SCTP.

Technically, supporting 4+/- protocols is perhaps not that big of a
deal...but
where's the value?

> 
> I think that HI and HAck from [mobile-ip] fast handovers would be
> a very suitable transport for some contexts that do not require
> rock-solid reliability, for those cases where they are available.
> I think that TCP or SCTP would be just fine for a lot of contexts
> that do require high reliability.  If we don't have HI and HAck
> available, but we have contexts with requirement for very low
> latency, then we can decide whether the contexts should be 
> encapsulated
> in ICMP, UDP, or some IP-level option.

Again, I have no problem ( at least at this point) with saying that the 
designer can run CT over one of a number of protocols, say they are UDP,
SCTP, ICMP, TCP - I do have a problem with the idea that each feature CT
will
run over different protocols. Now, instead of one context transfer, you have
at least one for each transport protocol used (assuming feature CTs that use
the same transport can be multiplexed onto one frame). This exacerbates many

issues such as transfer delay, ordering, updates synchronization, etc.

> 
> >   Obviously, I believe that it is possible to convey all 
> feature contexts with
> > one CT protocol, running over one (to be determined) transport.
> 
> I can't see this.  Some contexts have to be transferred with very
> low latency, and have low reliability requirement.  Some contexts
> have much more relaxed latency requirements, but have high reliability
> requirements.  The same transport protocol is unlikely to work for
> both.

The only reason you would separate the transports in this case is if there
was an advantage to optimizing for the "low performance" requirements. That
is,
what is the problem with delivering a feature context with a lower latency
or
higher reliability? 

There is certainly more overhead in adding a second, higher latency or lower

reliability exchange then there is in putting all the context on a transport
that met the most demanding requirements.

Usually, achieving low latency is in opposition to high reliability either
because
of the processing overhead with FEC, or the loop response latency of a BEC
(backward
error control). The total context is relatively small in terms of the number
of bytes, and the latency requirements are not sensitive to the microseconds
required
to encode and decode FEC (particularly if for proactive CT).

A number of ideas kicked around lately almost seem imply the use of CT for
state 
synchronization between ARs. I really hope this is not the case. If so, it
really
does not jibe with the vision I have of what CT is trying to accomplish,
with is a
loose, best effort approach to improving the seamlessness of handover. 

State synchronization can be done much more effectively below L3, without
the overheads
of IP+transport.

Gary

> Charlie P.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 9 Aug 2002 16:44:31 -0500

As far as AR not supporting TCP or SCTP, I don't think anybody is designing
CT to an arbitrary node across internet.
I will only do CT with some network I know and have some kind of
relationship with, but that is another issues.
 
the point is, if somebody wants to use CT for their feature and wants to use
TCP or SCTP for reliability for that feature context transfer then, that
designer has to make sure TCP/ SCTP are presented on those AR' s stacks. 
 
I think the point here is that CT is designed to be independent of transport
protocol and it is already stated in the suggested text. No transport
protocol is suggested or mandated. CT is not making the use of those
protocols a must, 
From the last year's experience, we know that trying to mandate one specific
transport protocol for CT for all features won't lead to a consensus. Lets
drop the discussion on transport layer of choice...
I think transport protocol discussion for each feature, has to be diverted
to the group that handles that feature.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, August 09, 2002 11:59 AM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Charlie: 

> From: Charles E. Perkins [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Certainly. 

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 9 Aug 2002 16:44:31 -0500

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, August 09, 2002 11:59 AM
To: 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Certainly. 

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 12 Aug 2002 11:19:21 -0400

Charlie:

  First of all, thanks again for your thoughtful replies.

> Sent: August 9, 2002 19:49
> > solution within the requirements document?
> 
> O.K.  I agree that it's not a requirement to use those protocols.
> But I think that we should _expect_ that the eventual solution may
> require that we make use of multiple transport protocols.
> 
> > isn't a problem. However, if one starts mapping ct 
> information into option
> > fields of various protocols, the mappings will very likely 
> change due to the
> > differences in protocol syntax. IPv4 vs. IPv6 seems to be 
> the most pronounced
> > example.
> 
> I'm happy to model context as data, not option fields.
> However, it could be (e.g., in the case of QoS) that the
> context affects the fields of various protocols.  In fact,
> taken abstractly, all the cases I care about can be modeled
> as affecting some fields of some protocol's data fields.
> This is even true for buffering, and security contexts, right?

You lost me a bit here. I was referring to the idea that the context
would be embedded into option fields of the transport protocol. This
would be the same as saying, for example, that SIP messages would be
encoded into the header of an IPv4 packet. Whether you can or not,
I believe it is simply bad design.

The options of a transport protocol may be changed to select particular
transport characteristics. This completely different from encoding the
context into the transport options.

> 
> >                     The real issue here is whether the CT 
> capability is
> > fulfilled with a single protocol or a suite of protocols. I 
> believe the former
> > is a preferable solution, if the protocol complexity is 
> manageable, which I
> > believe it is.
> 
> Again, I'm happy if there can be a single solution.  But, if I were
> given the choice of ICMP for some contexts, and TCP for others, vs.
> waiting two more years for XCTTP (unknown context transfer transport
> protocol), I'd go for using two transports.

I do not really believe that there is much to be gained in creating yet
another transport protocol. My point is that if you are going to transfer
come of the context with TCP, for example, then you might as well transfer
all of the context with TCP. 

We had a discussion, way back, about whether all the context can fit into
one IP packet. Since the context was, and is still pretty much undefined,
we could not reach a definitive solution. However, there doesn't seem to
be any compelling reason to believe that context will typically exceed even 
1500 bytes. Regardless, even if the context data does exceed the capacity of
a single IP frame, we are not talking about megabytes of data. The benefit 
of splitting the context between different transport protocols just does not
out weigh the detriments.

At this point, may I suggest that we clarify the requirements to remove the
implication that each feature context must have a separate transport
protocol.
I think that each feature context analysis should outline the ideal and 
adequate transport requirements, and choice of one or more then one
transport
should be left to the network designer.

> 
> > We have pretty well decided that CT capability involves at 
> least two protocols
> > (above IP): a CT containerizing protocol, and a transport protocol.
> > Two is still better then a gaggle of protocols, IMHO.
> 
> What's a containerizing protocol?  Can't we just have data formats
> without having to do distributing processing to collect the data?

Not sure how you segued into distributed processing. I think the idea
that CT is a container protocol has been discussed in the wg for some
time now (ok, perhaps "containerizing" is a poor choice of words). 
Basically, what I believe has been discussed are encapsulated chunks 
of feature context (the context is "containerized") that are ferried
about by a transport protocol. 

> Gaggle is, by the way, a great word.  Is ICMP plus TCP approximately

Thanks.

> equal to, or less than, a gaggle?

Well, two geese is still a gaggle, as far as I know. Nonetheless, what's 
the criteria/requirement that prevents each feature context from having 
it's own transport protocol? 

At this point, I still see ICMP plus TCP as being one too many protocols. 

> > Well, this assumes that the ARs have end-point stacks for 
> all of the transport
> > protocols, and management interfaces, etc. Most routers 
> have ICMP/UDP support.
> 
> > Technically, supporting 4+/- protocols is perhaps not that 
> big of a deal...but
> > where's the value?
> 
> As I mentioned above, if you can make a single protocol do it, I'll
> be happy (still wondering about that containerizing, though).

Yes, as I said, bad choice of word. The "containerizing" would be something
that the CT protocol would "do" - e.g. CTP needs to define the format of
the container, with type codes, length fields, etc. - whatever is decided
is necessary to ensure that the feature context is opaque to the transport,
but still can be extracted at the receiver.
 
> >> encapsulated in ICMP, UDP, or some IP-level option.
> > 
> > SCTP, ICMP, TCP - I do have a problem with the idea that 
> each feature CT will
> I can see a simple solution for this:
> 
> 1. Find the most urgent context.  Encapsulate it using the transport
>    it specifies (which won't be TCP, I reckon, for extremely urgent
>    contexts).   Fill the rest of the context feature data structure

Why not? I agree if the intent were to set up a TCP connection every
time you wanted to perform CT, but at least for networks where the
ARs are wired together, a single TCP connection between two ARs can be 
established and kept open, can it not, to handle all CTs.

>    with the most urgent other contexts that will fit, and which are
>    compatible with the chosen transport.  If the chosen transport
>    is not a reliable transport, schedule a retransmission if any
>    context transfer requires acknowledgement.

I seem to sense a proposal here to layer an ACK/retransmission protocol
on top of ICMP. Seems like you are really back to creating XCTCP, but
with the (possible erroneous) assumption that ICMP is an appropriate
starting point.

> 
> 2. If there are any contexts left, goto (1).
> 
> timeout(retransmission_timer) {
> 	retransmit the packet;
> 	if (not-enough-retries-yet) {
> 		schedule_another_retransmission();
> 	}
> }

Curious. Are you suggesting one exchange per feature context (i.e.
with each feature context to be transferred you initiate a new transport
exchange, which requires one or more IP packets)? If so, I would say
that you have already lost the battle to enhance seamlessness. 

Why not simply put all feature contexts into one transport exchange?
Which hopefully means, one IP packet.

BTW: if the goal here is to merge CT with the HI/HACK mechanism for 
MobileIP, then the intent is misguided. CT is supposed to work in
scenarios where MobileIP is not present. Certainly requiring the
network to implement HI/HACK simply to allow part of the CT to occur
is wrong.

> 
> process_ack {
> 	delete_retransmission_timeout();
> }
> 
> > is, what is the problem with delivering a feature context 
> with a lower
> > latency or higher reliability?
> 
> How do you like my high-level example above?   It's an example, not an
> attempt to enforce a particular solution.  Of course there are a huge
> number of details omitted, like what the receving AR does with the
> various kinds of features, but those are straightforward details.

See comments. I am beginning to believe that this debate is more around
trying to incorporate HI/HACK into CT then it is about what transport 
protocol CT needs. Please tell me why am mistaken.

Cheers,
Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 12 Aug 2002 14:18:42 -0400

Hello again Charlie:

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: August 12, 2002 11:54
> It seems to me that we're finally getting to the heart
> of the discussion...
> 
> Gary Kenward wrote:
> 

*snip*

> But this either implies that one keeps TCP sessions open
> with "neighbouring" access routers (as you mention later),
> or that one accepts more latency.  This "nearly" places a
> dependency on the future "access router discovery"
> protocol, which I think would be a serious mistake.
> Otherwise, no contexts could be transferred in less
> time than it takes to start up TCP, which would also
> be a mistake, it seems to me.

I agree. TCP has limitations for short bursts of traffic such as CT.
*Except* for the cases of an ad-hoc network, or a network with mobile
routers, I do not see any reason why a TCP connection cannot be simply 
opened and kept open.

I have never understood the rationale for "discovering" a new wireless
network and then requesting a handover and thus a transfer. I have outlined
my reasons in other emails, so I won't get into it here. 

*snip*

> The problem isn't MTU, it's startup latency for TCP, which
> could get into quite a few milliseconds.  All of this detracts
> from the overall delay budget for real-time applications
> which can have quite stringent bounds.  The more we push
> those bounds out towards longer delays, the fewer applications
> will experience "smooth" handovers.  Even if TCP can handle
> voice handovers in some restricted domains, are you confident
> it can handle future voice/video synchronized streams?

See above. Any overhead introduced during a handover takes us away
from seamlessness.

And so, following your logic, I question the rational with doing CARD => 
CT => handover with a video stream.

> The actual requirement for some contexts is low latency, not
> separate transports.  The other actual requirement (for other
> contexts) is reliability (again, not separate transports).  I do not
> have confidence that TCP can meet _both_ requirements.

You are presuming here that the handover can proceed without the
second context. Otherwise, the TCP based CT still has to complete before
the handover can be completed (e.g. the packets can be forwarded at
the new AR with the same services and service characteristics). And,
if the "fast CT" completes before the "reliable CT", how does the
target AR incorporate the late context, given that, by definition,
the "fast CT" is being used to forward packets (if it is not
being used, then it clearly didn't need to be at the destination AR
so quickly).

I have a feeling, a strong feeling that this is all moot. I do not
know of any context that can be transferred unreliably - that is,
there has to be a reasonable assurance that CT will succeed in order
for it to "enhance" handover. If a CT fails as a consequence of an
unrealizable transport being used, what is the result?

By reasonable assurance, I go back to what I stated in reply to James:
handovers will fail. However, handovers failures due to CT failures
must not be relatively insignificant (e.g. <<1%).

*snip*

> Are you really willing to make the restriction that [seamoby]
> only deals with such networks that satisfy this criterion?

It would be preferable if we had a protocol that was both fast
and reliable - e.g. one that optimized for very short bursts of
data. However, we (seamoby) are not going to be defining that protocol,
as far as I can tell.

I'm still waiting for a practical description of a wired network or group
of wired networks where this "restriction" is impractical. For a handover
to occur seamlessly between two networks, many, many facilities have to
be pre-established. It would seem to me that requiring a tunnel for CT
between the two is a very small additional requirement.

> I'm not so particular as that.

Regardless, the idea of defining an ack/retx capability on top of UDP/ICMP
is still transport protocol design. Arguably, TCP is simply UDP with
ack/retx
and window flow control (and a pile of other stuff designed to make it all
work in various situations). 

*snip again*

> That's what my "program" does!  Please have another look.

No it doesn't. It puts each context into it's own transport protocol. That's
not, in my view, one transport exchange (each protocol sets up it's own 
exchange), and not one IP packet, in anyone's view.
> This is in no way the intention of what I wrote.  However,

Good to know. But then, I am confused over the relevance of HI/HAck to
the discussion. 

> I also believe that any reasonable solution SHOULD work
> with fast handovers.  Otherwise, what's the point?  Even so,

The critical phrase here is "work with" - CT MUST work with
MobileIP (it's in the charter I believe). However, how it works
is another issue.

> there may be other protocols that achieve similar goals, and
> in those cases the CT design should still work fine.
> 
> I hope by now it is obvious!  Nothing I said should be
> interpreted to draw that conclusion.  Do you see now?

I guess I shall remain confused. You introduced HI/HAck as a mechanism
for CT. I don't see the relevance. If the *only* context I have to
transfer fits into HI/HAck and HI/HAck provides the necessary transport
characteristics, then yes, it would be nice if CT could run over Hi/HAck.
Does this mean that CT should be tailored so that it runs over Hi/HAck?
I guess it should be shown that tailoring CT for this purpose is
significantly
superior then running CT in parallel (or before, as with in "proactively").

I have no idea how to proceed from here. 

John L. is right, we are back in the same rat-hole we were in more then a
year
ago. There is little agreement as to what the transport service requirements
are,
whether they are feature context specific, mutually exclusive, available in
existing
protocols, etc., etc., etc. Those that do not pay attention to history, are
doomed
to repeat it.

Perhaps John can come up with a set of requirements for transport. How this
can be
done without going through the requirements for each feature context will be
a 
challenge, for the debate always returns to the (perceived) differences in
transport
service requirements, and the (perceived) exclusiveness of those
differences.

Onwards and downwards,
Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Aug 2002 10:19:40 -0400

Charlie:

> Sent: August 12, 2002 22:49
> Continuing...
> I agree this would be possible, and would provide
> reasonable performance in a lot of cases.  It would
> penalize mobile nodes moving to "uninitialized"
> access routers that do not need reliable transfers,
> and for that reason seems to be unnecessarily heavy
> handed.  So, I'd say it's not the best approach.
> 

I don't understand the concept of an "uninitialized access router".
Is this a router at the north pole that few people roam within range of? 

Roaming happens between adjacent cells. If there is activity in a cell,
there's likely to be roaming. Making it a condition that an AR have
an open TCP connection to it's neighbour for it to support roaming is 
not burdensome. It's the same as saying that the AR have the various
capabilities
to support roaming.

> > And so, following your logic, I question the rational with 
> doing CARD
> > =>
> How about "Handover + CT"?  That would work.

How about CT => handover, that would work better :-)

> > second context.
> Not exactly.  In my opinion, we MUST arrange it so
> that all handovers can complete even if all context
> transfers fail.  Successful context transfers will have
> the effect of improving performance.
> 
> Thus, one effect of this is that, yes, the handover could
> complete without the second (or any other) context.

Agreed. But it will not be true in all cases. Consider: should security
context transfer be timely or reliable? Some might have a problem with it 
being unreliable. However, allowing forwarding to proceed at the
new AR without security ct because it is being transferred with a reliable
transport is almost the same as security ct being unreliable.

Note: this is the point we came to during the last transport requirements
discussion. So much depends on what the feature contexts each might require,
and under what conditions. Since the working group has chosen not to work on
the feature context requirements, yet, no new information is available.

> How about header compression?  If the state does
> not make it, then it can be re-established.

Sure. Not seamless though. Particularly if the compression is
not ROHC. In truth, everything can be re-established. The trick
for establishing seamlessness is to avoid this time consuming
activities.

> 
> How about QoS?  If the state does not make it, the
> mobile node could renegotiate.
> 
> In fact, I think this is true for _all_ contexts: if the
> transfer fails, the mobile node has to be robust
> enough to renegotiate, re-establish, or request
> retransmission of data.

See above. 

It's all relative: performance gain relative to cost. If ct provides
seamlessness 50% of the time, and the rest of the time some renegotiation
goes on, then it's not worth implementing (users are typically conditioned
by the exception, not the rule, and so the frequency of seamlessness may
probably have to be as high as 80-90% to achieve customer satisfaction with
the service. Personally, I think it can, and should be higher).

> It's probably a great goal, but I can't see why you would
> want to restrict context transfers to only those scenarios
> offering high reliability.

Do you mean reliability of handover? Reliability of handover is not
the same as reliability of the bearer packet transport. Reliability of
handover impacts customer perception of a smoothly operating, dependable,
predicable service. In truth, above a lower limit, consistency in handover 
performance is more important then maximization (e.g. variance in
performance
is more noticeable and irritating to the user).

From a personal perspective again (for I have not seen any human factors
studies
on the subject), I believe that a successful wireless offering means that
the
user receives a consistent, predictable communications service, and does not
experience *any* handovers (but perhaps, the *rare* drop of a session). The
user should not have to care about "cell boundaries" (I'm talking about real
users, not techies at IETF conferences :-} ).
> Your statement is not true for the prototype implementation
> we have.  Requiring another tunnel for CT is just not
> necessary, and isn't such a trivial requirement anyway.

Well, I guess that I cannot speak to your implementation. It might help
if you explained to the wg why establishing and maintaining a TCP connection
between two ARs is non-trivial for your implementation. Nothing is more
useful then real implementation experience.

> > and window flow control (and a pile of other stuff designed 
> to make it
> > all
> A pile here, a pile there, and pretty soon you're talking
> about real protocol.

Yup. So either we are using an existing protocol, with no modifications, or
we
are designing a new transport protocol. Talking about putting ack/retx
on UDP/ICMP is miss-leading, it would be a new transport protocol.

> > No it doesn't. It puts each context into it's own transport 
> protocol.
> > That's
> Well, with apologies to others, here is what I said:
> 
> The third sentence refutes your characterization.  How many
> transports do you think there are, anyway?

"Encapsulate it using the transport it specifies".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note: one thing that bothers me about this discussion is that idea that
TCP is inherently slow. On a good link (i.e. just about any
wired link in a well engineered network) and with no congestion in any
of the nodes (which is easily done using Diff Serv and traffic engineering,
for example; and, just how many routers will be between two neighbouring
ARs? 
one? two?). An established TCP connection is just as fast as UDP.
> 
> Typically, there would be one packet per transport type, and
> that's unlikely to be more than two packets.

But I still do not see the advantage. In one scenario you have
feature contexts being transferred over individual transports,
in another (my ideal) you have all features multiplexed onto one
packet, and travelling to the destination AR in one packet. With
a "permanent" TCP connection to the new AR, the transit time is the
same as UDP/ICMP. If the packet gets "lost" and handover is in progress,
then the new AR has to decide if it should wait for the re-transmission,
begin forwarding the MNs packets, re-negotiate services, or drop the
session. *IF* a packet gets lost - do you think it is possible to
keep the packet loss probability in a well engineered network to below
1%? If so, then the last three options are probably appropriate options
(1 in 100 handovers require re-negotiation, perhaps while the forwarding
proceeds with degraded service). I think that .001% packet lost probability
is easy to achieve - this is not transport across the global internet.

BTW: I am not a proponent of TCP for the transport. Indeed, if you follow
the above argument, and loss rates of <1% are easily achievable, then 
UDP should be reliable enough.

> They are one good place to put context feature data, but
> not the only good place.

Good is subjective.

> 
> Put another way, if the old access router is already sending
> HI to the new access router, there's no reason that urgent
> context feature data should not be included with the base
> handover information.

And the reason for piggy-backing the information is to save one
packet transmission per handover? At the cost of having feature
ct's occur sequentially and asynchronously? It does not seem
worth the trouble, honestly.

> That's all I meant.
> Of course not -- depending on what you meant by "tailored".
> I think it should be convenient to do it either way.
> 
> Two packets takes longer than one.

Exactly. So you agree ct is faster sent over one transport packet.

> 
> > Onwards and downwards,
> > Gary
> 
> Somehow that means you are unlikely to welcome this response.
> But I'm trying to be constructive.

No, not at all. Just being sardonic. Sorry.

I think that, as with the last go round, we really need to get either
a ct solution out for everyone to debate, or we need to get some feature
context transport requirements analysis out for everyone to ponder and
debate.

All I want, is for the requirement wording to be changed to indicate that
goal is to minimize the complexity of the transport, with one transport
protocol for ct being a desirable objective. 

Cheerio,
Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Aug 2002 10:19:40 -0400

See above. 

Good is subjective.

Cheerio,
Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Aug 2002 14:40:13 -0400

See above. 

Good is subjective.

> But I'm trying to be constructive.

No, not at all. Just being cynical about the state of the world. It was
not a comment on our conversation. Sorry for the misconception. And besides,
downwards can be a good thing...

Cheerio,
Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 13 Aug 2002 14:40:13 -0400

See above. 

Good is subjective.

Cheerio,
Gary