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

[Rajeev Koodli <[e-mail]>]

[e-mail] wrote:

>
> > Hi James:
> >
> > I have the impression that CT is an optimization for NSIS as it can help avoid sending signaling payload bits over MN-new AR link at handoff time. Now, this assumes that there is only one feasible target for handoff. Then, CT is
>
> 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.
>
> [Hemant] Does reduction of latency in establishing QoS along the new packet path count as transport performance enhancement? Also, is it not (at all) a goal of CT to save wireless bandwidth for redundant signaling on a new AR -

If there is a need for re-establishing QoS along the new path, then yes. And,
CT can trigger such a signaling when needed, and NSIS is probably the right
place for this signaling. In the NSIS interim meeting, there seemed to be
favorable response to this thinking when I made this point.


> MN link? In other words, is it appropriate to view CT as a tool to enhance seamlessness of handoff, or should be limited to the role of RTP/TCP performance booster (did you mean header compression there?). Also, are you

Ofcourse CT is meant to enable "seamless handover", which includes
transport protocol performance.

> suggesting that NSIS should design its independent AR-AR protocol.?

No. I am not saying that NSIS should design its own AR-AR protocol.
However, it's for NSIS folks to decide why/when/how such a thing is
needed :-)
BTW, what I meant in my previous e-mail was that CT was conceived
when NSIS was not on radar. I see NSIS might be useful in providing
a MN - AR signaling mechanism that would establish feature contexts.
However, feature contexts could be established by other means as well.


>
> > simply transferring QoS description available at old AR to new AR. If the level of service available at new AR is greater or less that what CT has transferred, NSIS can take care of adaptation as the session continues from new AR.
>
> This was discussed earlier. In essence,
>
> - with some standard Profile Types, you would expect participating routers to
>     support a majority of the feature contexts. In the absence of additional
>     protocol support (e.g., CARD), transferring what you have is just fine. The
>      receiving router ignores the context(s) it does not understand.
>     London IETF was where we specifically had this discussion in depth.
>
> [Hemant] I did not mean readability or otherwise of CT bit layout at new AR when I said this. Level of service can imply for example increased/descreased available throughput. So, even if everybody understands profile types, values of service parameters could change (e.g. when you move from 2.5G to Operator WLAN and vice versa).
>

A Profile Type could encode the parameter values.

>
> - when a feature context type is not understood, CT should provide a notification.
>     Such a notification is also useful when a feature context is partially understood.
>     This notification could be used as a trigger to engage in NSIS signaling.
>     This was presented at the NSIS interim WG meeting.
>
> >
> >
> > If there are more than one feasible targets for handoff (this is where CARD may come in play), then the situation is little involved. If we can limit CARD negotiation to new AR resource check alone (as simple as bandwidth available on new AR-MN link or new AR outgoing interfaces), then the NSIS data path QoS signaling payload will be automatically available at new AR as a result of CARD negotiation procedures. On the other hand, if we have to check resource on new AR - CN data path also before concluding anything about handoff target, some NSIS signaling could occur along data path before CARD.
> >
>
> Ok. When CARD is available, it can provide input to CT.
>
> [Hemant] But then new AR would know during CARD negotiation itself what the new context is? Do we need another CT (at least for QoS) after CARD has executed?
>

What is CARD doing here ? Figuring out capability or actually transferring
contexts ? I am not sure..
I think the two should be treated separately.

-Rajeev


>
> [Hemant] Hemant
>
> -Rajeev
>
> >
> > Hemant
> >
> > -----Original Message-----
> > From: ext James Kempf [mailto:[e-mail]]
> > Sent: 08. July 2002 12:39
> > To: Chaskar Hemant (NRC/Boston); [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [Seamoby] RE: [NSIS] Re:
> > draft-westphal-nsis-qos-mobileip-00.txt
> >
> > Could CT be viewed as an optimization of NSIS signaling?
> >
> >             jak
> >
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> > Sent: Monday, July 08, 2002 9:20 AM
> > Subject: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
> >
> > > Hi Gary:
> > >
> > > Some comments inline:
> > >
> > > -----Original Message-----
> > > From: ext Gary Kenward [mailto:[e-mail]]
> > > Sent: 08. July 2002 12:00
> > > To: '[e-mail]'; 'NSIS'
> > > Subject: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00.txt
> > > Sensitivity: Confidential
> > >
> > >
> > > I finally managed to find time to read through Cedric's and Hemant's draft.
> > > Overally, I think it is a good description of one possible integrated
> > > approach.
> > >
> > > [Hemant] Please note that the Edge Signaling (MN-AR and AR-AR) and Data Path Signaling (e2e if you will) are not "tightly
> > integrated", i.e., they help each other but do not rely on each other (though I admit that the current writeup makes that
> > impression). In other words, Data Path Signaling can work (at handoff time) even if Edge Signaling fails.
> > >
> > > The one general comment I would like to offer up at this time, is that while
> > >
> > > the draft does a good job of integrating MIP, CT and NSIS concepts, the
> > > proposed solutions for QoS negotiation between MN and AN (e.g. the use of
> > > the
> > > CIN message) is NSIS not CT.
> > >
> > > [Hemant] Point well taken.
> > >
> > > CT is concerned with the transfer of forwarding service context between
> > > ANRs.
> > > NSIS is concerned with the signalling of service requirements. Thus, the
> > > issue
> > > is not how to interwork the "CT" CIN, for example, with NSIS signalling, but
> > > how
> > > the CIN, etc., form part of the NSIS solution.
> > >
> > > [Hemant] I agree. The basic idea is that if CT can help avoid MN-new AR NSIS signaling at handoff time, it is a good proposition.
> > Note that context can be constructed at old AR using the information supplied to it by NSIS MN-old AR message at session initiation,
> > which can be transported to new AR in CT. If CT fails, one should use MN-new AR NSIS signaling at handoff time, albeit at certain
> > loss of seamlessness.
> > >
> > > [Hemant] Thanks, Hemant
> > >
> > > This is not simply an issue of adherence to Seamoby/NSIS models or charters.
> > > The intention has always been that CT work as a context transfer mechanism
> > > with a variety of mobility and service signalling solutions. There is a
> > > significant
> > > benefit in the real world to be realized in keeping the context transfer
> > > solution
> > > (CT) independent from the service signalling solution (NSIS) (and the
> > > mobility
> > > solution - MIP or whatever). I would think that there is also a benefit to
> > > keeping
> > > the MN to AR service signalling independent of CT.
> > >
> > > Stated a different way, do we really need two separate solutions for over
> > > the air
> > > (MN to AN) service signalling?
> > >
> > > Regards,
> > > Gary Kenward
> > >
> > >
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/seamoby


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