[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
Well, the only question I have is whether we
should be writing down requirements for which
there isn't actually a problem in the current crop
of protocols. This capability as written is
already available with RSVP. I sure hope we're not
headed down the path of writing requirements for a
new protocol from a clean slate here. IMO, we
should concentrate on the inadequacies of the
current crop with respect to mobility. Even if
there were a new protocol, we wouldn't be writing
its general requirements, after all.
ObReq: * QoS signaling protocols should
differentiate between intentional
topology changes and flapping with their
damping strategies.
Mike
ext Glenn Morrow writes:
> This reads very good to me.
>
> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: Wednesday, April 18, 2001 10:54 AM
> To: mip-qos@research.nokia.com
> Subject: RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
>
>
> Can we condense the discussion about this issue of not being able to get old
> QoS on the new path as the following requirement:
>
> "The new end-to-end path may not support the old QoS agreement
> because one or more routers or links are already at capacity. The QoS
> mechanism MUST have provisions to handle this situation. It MAY also
> be required to inform the MN about the impending QoS degradation. The
> action taken in response to this situation (adapt, gracefully degrade,
> re-negotiate or tear down) and the decision point (MN or service
> provider policy) of the action are solution specific issues."
>
> > -----Original Message-----
> > From: marc.greis@nokia.com [mailto:marc.greis@nokia.com]
> > Sent: 18. April 2001 11:29
> > To: mip-qos@research.nokia.com
> > Subject: RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
> >
> >
> > Mike,
> >
> > > -----Original Message-----
> > > From: ext Michael Thomas [mailto:mat@cisco.com]
> > > Sent: 18 April, 2001 9:28 AM
> >
> > > As far as requirements goes, are there any
> > > cases where this is not purely a local policy
> > > decision of the mobile node? If there are, then
> > > there should be a requirement that the mobile
> > > node be the final arbiter of what is "acceptible
> > > QoS" based on local policy.
> >
> > I agree that the mobile node should make the final decision
> > (though you
> > probably can not prevent the service provider from making the
> > decision for
> > the mobile node). However, I think that creates the
> > additional requirement
> > that there needs to be a mechanism for informing the mobile
> > node of the fact
> > that the QoS has been downgraded. I don't think that it is a
> > good solution
> > (in all cases) to wait for the user to notice that the QoS has become
> > inacceptable.
> >
> > > Note that this may actually be a requirement on MIP/SEAMOBY.
> >
> > Actually, this may be an even broader requirement for QoS
> > mechanisms in
> > general. Mobility is not the only case where QoS can degrade.
> >
> > Marc
> >
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
> <TITLE>RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=2>This reads very good to me.</FONT>
> </P>
>
> <P><FONT SIZE=2>-----Original Message-----</FONT>
> <BR><FONT SIZE=2>From: Hemant.Chaskar@nokia.com [<A HREF="mailto:Hemant.Chaskar@nokia.com">mailto:Hemant.Chaskar@nokia.com</A>]</FONT>
> <BR><FONT SIZE=2>Sent: Wednesday, April 18, 2001 10:54 AM</FONT>
> <BR><FONT SIZE=2>To: mip-qos@research.nokia.com</FONT>
> <BR><FONT SIZE=2>Subject: RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=2>Can we condense the discussion about this issue of not being able to get old</FONT>
> <BR><FONT SIZE=2>QoS on the new path as the following requirement:</FONT>
> </P>
>
> <P><FONT SIZE=2>"The new end-to-end path may not support the old QoS agreement</FONT>
> <BR><FONT SIZE=2>because one or more routers or links are already at capacity. The QoS</FONT>
> <BR><FONT SIZE=2>mechanism MUST have provisions to handle this situation. It MAY also</FONT>
> <BR><FONT SIZE=2>be required to inform the MN about the impending QoS degradation. The</FONT>
> <BR><FONT SIZE=2>action taken in response to this situation (adapt, gracefully degrade,</FONT>
> <BR><FONT SIZE=2>re-negotiate or tear down) and the decision point (MN or service</FONT>
> <BR><FONT SIZE=2>provider policy) of the action are solution specific issues."</FONT>
> </P>
>
> <P><FONT SIZE=2>> -----Original Message-----</FONT>
> <BR><FONT SIZE=2>> From: marc.greis@nokia.com [<A HREF="mailto:marc.greis@nokia.com">mailto:marc.greis@nokia.com</A>]</FONT>
> <BR><FONT SIZE=2>> Sent: 18. April 2001 11:29</FONT>
> <BR><FONT SIZE=2>> To: mip-qos@research.nokia.com</FONT>
> <BR><FONT SIZE=2>> Subject: RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Mike,</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> > -----Original Message-----</FONT>
> <BR><FONT SIZE=2>> > From: ext Michael Thomas [<A HREF="mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
> <BR><FONT SIZE=2>> > Sent: 18 April, 2001 9:28 AM</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> > As far as requirements goes, are there any</FONT>
> <BR><FONT SIZE=2>> > cases where this is not purely a local policy</FONT>
> <BR><FONT SIZE=2>> > decision of the mobile node? If there are, then</FONT>
> <BR><FONT SIZE=2>> > there should be a requirement that the mobile</FONT>
> <BR><FONT SIZE=2>> > node be the final arbiter of what is "acceptible</FONT>
> <BR><FONT SIZE=2>> > QoS" based on local policy. </FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> I agree that the mobile node should make the final decision </FONT>
> <BR><FONT SIZE=2>> (though you</FONT>
> <BR><FONT SIZE=2>> probably can not prevent the service provider from making the </FONT>
> <BR><FONT SIZE=2>> decision for</FONT>
> <BR><FONT SIZE=2>> the mobile node). However, I think that creates the </FONT>
> <BR><FONT SIZE=2>> additional requirement</FONT>
> <BR><FONT SIZE=2>> that there needs to be a mechanism for informing the mobile </FONT>
> <BR><FONT SIZE=2>> node of the fact</FONT>
> <BR><FONT SIZE=2>> that the QoS has been downgraded. I don't think that it is a </FONT>
> <BR><FONT SIZE=2>> good solution</FONT>
> <BR><FONT SIZE=2>> (in all cases) to wait for the user to notice that the QoS has become</FONT>
> <BR><FONT SIZE=2>> inacceptable.</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> > Note that this may actually be a requirement on MIP/SEAMOBY.</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Actually, this may be an even broader requirement for QoS </FONT>
> <BR><FONT SIZE=2>> mechanisms in</FONT>
> <BR><FONT SIZE=2>> general. Mobility is not the only case where QoS can degrade.</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Marc</FONT>
> <BR><FONT SIZE=2>> </FONT>
> </P>
>
> </BODY>
> </HTML>