RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt

Hi James:

Please see inline:

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: 10. July 2002 18:15
To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli; Chaskar Hemant (NRC/Boston)
Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Re:
draft-westphal-nsis-qos-mobileip-00.txt

I guess I didn't make my point clear.

The point I was trying to make is that given CT of QoS context succeeds, NSIS signaling at the new access subnet is
unnecessary. Thus, it could be viewed as a kind of optimization. If CT fails, then signaling would be needed.

[Hemant] If you mean here that NSIS signaling *between MN and new AR* at the new access subnet is unnecessary, then I agree with you.

I did not mean to imply that any changes were required in the generic CT requirements (though perhaps there would need to be
some changes in the QoS specific context definition).

[Hemant] If CT is merely a carrier protocol, it should be easy to define NSIS payload types to be carried within it. So, I agree that changes may not be required to requirements.

Is this accurate, from the NSIS viewpoint? One case where I could see it not being accurate is if there were some changes
required behind the access router in order to obtain QoS for the mobile on the new router, but perhaps there are others.

[Hemant] Yes, that is one case where NSIS will need to do signaling even after CT. There is also another case, which is when service at new AR is different than that at old AR (2.5G to WLAN handoff). Since, negotiation is out of scope of CT, CT would merely transfer old service description (say thrpt. = 100 kpbs) to new AR. But new AR can actually offer 1000 kbps to flow. NSIS has to later adapt to such changes. Of course, this function could be delegated to CARD, then transferred QoS context will say 1000 kbps in the first place. -Hemant

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "'James Kempf'" <kempf@docomolabs-usa.com>; "Rajeev Koodli" <rajeev@iprg.nokia.com>; <Hemant.Chaskar@nokia.com>
Cc: <gkenward@nortelnetworks.com>; <seamoby@ietf.org>; <nsis@ietf.org>
Sent: Wednesday, July 10, 2002 11:58 AM
Subject: RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt

> James,
>
> As much as I like to see a clean interaction between CT and NSIS,
> I don't see any reason why CT needs to play the role of NSIS optimization,
> not to forget the NSIS didn't even exist back then.
>
> CT is simply a tool you need in your seamless mobility toolbox, it
> eventually
> involved into a container carrying any context you like (even non-IP
> context, as
> long as it is feasible). The profile types, that Rajeev mentioned is aligned
> with
> this line of thinking.
>
> I seriously advise against going back and change CT
> requirements for the sake of optimizing NSIS, which at this point we don't
> know
> what it is. A couple of months from now, we have to revise CT because of a
> security
> related protocol, later for something else.....
>
>
> The later we wait for CT standardization, the more home brewed versions are
> going to pop up, just like Behcet mentioned.
>
> My 1.5 cents (lower dollars)
>
> Madjid
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, July 08, 2002 4:37 PM
> To: Rajeev Koodli; Hemant.Chaskar@nokia.com
> Cc: gkenward@nortelnetworks.com; seamoby@ietf.org; nsis@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00.txt
>
>
> > CT is an optimization to avoid signaling and the associated overheads, and
> maintain
> > desirable transport (RTP/TCP)performance. A historical note: CT was not
> designed
> > to be an optimization for NSIS.
> >
>
> Do you mean that the requirements weren't so designed? Because, to my
> knowledge, the WG has not yet settled on a design. We are
> currently awaiting IESG feedback on our requirements. The problem statement
> was just approved by the IESG.
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby