Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 15:45:39 -0500

Hi Charlie,

Sorry for the delay.
Yes, and that was one the reasons we could not agree on
the reliability requirements. Other reasons were:
the uncertaintly about the underlying protocol, i.e. ICMP
or SCTP or UDP or something else, plus the timing effects
of retransmissions of context on handoff. 

BR,
Madjid
-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, April 05, 2002 5:08 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'James Kempf'; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

(I trimmed the mailing lists and some of the trailing messages)

Hello Madjid,

The problem is that the reliability needs depend on the context
feature type.   Some contexts should be transferred reliably, and
some are not so crucial.  Reliable transfer for header compression
context is not as crucial as, say, security context -- for
various reasons, but at least because retransmission for the
header compression state would take too long.

Regards,
Charlie P.

Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> Well, you are opening a can of worm that took seamoby 3 months
> to close without any results. People could not agree on the
> reliability needs of CT. We added a reliability mechanism to our
> CT proposal that covered both retransmission and updates.
> 
> Madjid
> 
> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, April 05, 2002 12:22 PM
> To: Rajeev Koodli
> Cc: Gary Kenward; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> Agree.
> 
> But I don't see anything in the CT requirements about handling CT
> failure.
> 
> ???
> 
>             jak
> 
> ----- Original Message -----
> From: "Rajeev Koodli" <[email-masked]>
> To: "James Kempf" <[email-masked]>
> Cc: "Gary Kenward" <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, April 05, 2002 10:02 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> > James Kempf wrote:
> >
> > > Rajeev,
> > >
> > > I agree, but there is still an issue of how the AR would notify the
> MN
> > > if CT fails. Is this covered by CT or not?
> > >
> >
> > This notification should be covered by CT.  We should offer
> > seamless handover to NSIS :-) Seriously, this concerns
> > robustness of CT protocol.
> >
> > -Rajeev

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 09 Apr 2002 14:05:49 -0700

Hello Madjid,

I think that the underlying protocol has to be selected in
order to meet the needs of the contexts that are going to
be transferred.  These needs ought to be encoded and discernible
as part of the definition of the context feature.  In our
framework, that would make it a property of the profile
type for the feature.

There are other details surrounding the aggregation of
various contexts for transfer as part of the same message
during handover.  Nevertheless, the process of figuring
out the detailed requirements is straightforward, and tedious.

My preference would be to allow several possibilities for
the transport protocol.  We might want to use SCTP for
context transfers that don't have time critical needs, or between
access routers that can maintain nailed-up connections.
We might want to use something else for context transfers
between access routers that have no such open connections,
or for transfers that exclude the possibility of retransmission
for the context feature data.  The underlying protocol could
itself be specified as part of the profile data for the
context feature.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 09 Apr 2002 14:05:49 -0700

Hello Madjid,

Regards,
Charlie P.