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

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

Charlie:

  First of all, thanks again for your thoughtful replies.

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: August 9, 2002 19:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: Re: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context
> Specifications
> 
> 
> 
> Hello Gary,
> 
> > Gary Kenward wrote:
> 
> > > 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?
> 
> 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.
> 
> >> 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.
> 
> 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. 

> 
> >> 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.
> 
> > 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.
 
> 
> >> 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.
> 
> 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();
> }
> 
> > 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?
> 
> 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
> Regards,
> Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Aug 2002 08:54:23 -0700

Hello Gary,

It seems to me that we're finally getting to the heart
of the discussion...

Gary Kenward wrote:

>                   ............

I am fine with your interpretation.

> all of the context with TCP.

But this either implies that one keeps TCP sessions open
with "neighboring" 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.

> out weigh the detriments.

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?

> should be left to the network designer.

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.

> about by a transport protocol.

Protocols "are" for "distributed processing", considered
abstractly.  However, I am happy with your characterization.

> it's own transport protocol?

None that I know of?!

>
> > >    ............               Now, instead of one context
> > transfer, you have

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

> with the (possible erroneous) assumption that ICMP is an appropriate

I'm not so particular as that.

> that you have already lost the battle to enhance seamlessness.

No, the text of my pseudo-program indicates probably
one packet per transport _type_, not one packet per
_context_.  So, if there are no contexts that require
reliability, only one UDP or ICMP packet would typically
be required.

> Which hopefully means, one IP packet.

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

> network to implement HI/HACK simply to allow part of the CT to occur

This is in no way the intention of what I wrote.  However,
I also believe that any reasonable solution SHOULD work
with fast handovers.  Otherwise, what's the point?  Even so,
there may be other protocols that achieve similar goals, and
in those cases the CT design should still work fine.

> protocol CT needs. Please tell me why am mistaken.

I hope by now it is obvious!  Nothing I said should be
interpreted to draw that conclusion.  Do you see now?

Regards,
Charlie P.

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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 12 Aug 2002 08:54:23 -0700

Hello Gary,

None that I know of?!

Regards,
Charlie P.