RE: Tomorrow's Telecon material
> -----Original Message-----
> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
> Michael.G.Williams@NOKIA.COM
> Sent: Friday, March 17, 2006 10:27 AM
> To: Srinivas.Sreemanthula@NOKIA.COM; STDS-802-21@listserv.ieee.org
> Subject: RE: Tomorrow's Telecon material
>
> The sense that came from the NIST presentation by Nada Golmie at the
> last meeting was that doing a full association (initial entry) into
some
> network types takes a long time. There is a complex relationship
between
> the speed of moving, the initial entry time for the handover, and the
> amount of time in advance that the handover process begins. It seems
> that if IS is used to facilitate initial entry into a network that has
a
> slow startup time, it will have to be quick...
[Vivek G Gupta]
Well if you plan to use IS in such a case, you presumably already have a
L3 connection. I am not sure this necessarily translates to a time
sensitive type transport requirement (at L3) for IS.
And the faster the
> mobility towards the slow startup network, the faster the services
that
> confirm the handover and facilitate it will have to be.
[Vivek G Gupta]
This seems to imply more of a time sensitive type requirement on
events/commands type of messages as opposed to IS exchanges.
>
> In addition, we might need to look at characterizing the fixed and
> variable portions of network entry startup time to help the MME in the
> MN or the network compute this timing.
>
> Best Regards,
> Michael
>
> -----Original Message-----
> From: ext Srinivas Sreemanthula
[mailto:Srinivas.Sreemanthula@nokia.com]
>
> Sent: Friday, March 17, 2006 9:40 AM
> To: STDS-802-21@listserv.ieee.org
> Subject: Re: Tomorrow's Telecon material
>
> Hi Vivek,
> I agree that proactive info queries are necessary for timely decisions
> which is certainly implementation dependent. But the nature of IS
> queries may involve (may be only L3) proxies, multiple transport
> connections and database queries. Putting a requirement for time
> sensitivity seems like a good idea to me. As you say this feature can
be
> used/misused but I don't see downside in using it either. The
intention
> is to ensure that the transport design allows for quick queries.
>
> Regards,
> Srini
>
> >-----Original Message-----
> >From: ext Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> >Sent: Friday, March 17, 2006 8:29 AM
> >To: Sreemanthula Srinivas (Nokia-NRC/Dallas);
> >Qiaobing.Xie@MOTOROLA.COM; STDS-802-21@listserv.ieee.org
> >Subject: RE: [802.21] Tomorrow's Telecon material
> >
> >>
> >>The need for timely delivery is more context based than it is
content
> >based. >I mean the urgency is known to only to the requesting entity
> >based on its >current conditions and therefore, setting a delay
> >requirement for transport >does make sense to me.
> >>
> >
> >It might help to understand this client context better, why/how did
the
>
> >client get into such a state...before getting too far into the
solution
>
> >space. For all you know the reason for this client state (context)
> >could just be a not so good implementation as opposed to a more
germane
>
> >design requirement.
> >If clients don't get information in a proactive manner and plan for
> >vertical handovers..., any amount of delay sensitivity built into
> >transport may not be good enough to rescue the connection under
adverse
>
> >situations. Also even if the use cases and requirements are quite
> >relevant, just a delay sensitive transport may not be good enough to
> >rescue such cases....
> >
> >That said, in general the transport should work well for most normal
> >cases. If there is a delay sensitive option in transport that comes
for
>
> >free I can easily see clients abusing it and using it as a default
> >anyway....
> >
> >Best Regards
> >-Vivek
> >
> >> -----Original Message-----
> >> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> >Behalf Of
> >> Srinivas.Sreemanthula@NOKIA.COM
> >> Sent: Thursday, March 16, 2006 3:46 PM
> >> To: Qiaobing.Xie@MOTOROLA.COM; STDS-802-21@listserv.ieee.org
> >> Subject: RE: [802.21] Tomorrow's Telecon material
> >>
> >> Qiaobing,
> >> Inline ...
> >>
> >> Regards,
> >> Srini
> >>
> >> >-----Original Message-----
> >> >From: ext Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
> >> >Sent: Thursday, March 16, 2006 3:51 PM
> >> >To: STDS-802-21@listserv.ieee.org
> >> >Subject: Re: [802.21] Tomorrow's Telecon material
> >> >
> >> >Srini,
> >> >
> >> >Sorry for missing your earlier question. But if only some
> >> >transactions are time sensitive, would setting a general delay
> >> >requirement for transport (i.e., forcing every transaction
> >to pay the
> >> >same cost) become a little wasteful?
> >>
> >> Srini>Good point, not all IS queries need it. But for some
instances
> >> that need it, the transport must support it. I think the transport
> >must
> >> provide this capability and also ability to switch off the
> >feature, if
> >> there is no need.
> >>
> >> >Moreover, IP in general is best effort network and every
> >transport is
> >> >at the mercey of the underneath IP layer. I don't know any
existing
> >> >mechanism that allows the sender to control the timeliness of
> >> >delivering a packet over an IP path (the most a sender can do is
to
> >> >set the TOS bits and pray).
> >>
> >> >The more common practice for a sender is to set a shorter
> >timer if it
> >> >knows that an out-going message is urgent so that it can engage
> >> >failure handling sooner if the expected response does not come
back
> >> >from the far-end.
> >> >
> >> >By the way, the only time sensitive IP transport defined in IETF
is
> >> >RTP, while neither TCP or UDP is considered time sensitive.
> >>
> >> Srini> I am not sure how this requirement will be supported. One
way
> >> would be use datagram services that don't need session setup.
> >>
> >> >
> >> >regards,
> >> >-Qiaobing
> >> >
> >> >Srinivas Sreemanthula wrote:
> >> >
> >> >> Hi all,
> >> >> I am answering to my own email. The need for timely delivery is
> >more
> >> >> context based than it is content based. I mean the urgency
> >> >is known to
> >> >> only to the requesting entity based on its current conditions
and
> >> >> therefore, setting a delay requirement for transport does make
> >sense
> >> >> to me.
> >> >>
> >> >> Regards,
> >> >> Srini
> >> >>
> >> >>
> >> >>>-----Original Message-----
> >> >>>From: ext Srinivas Sreemanthula
> >> >>>[mailto:Srinivas.Sreemanthula@nokia.com]
> >> >>>Sent: Saturday, March 11, 2006 8:18 AM
> >> >>>To: STDS-802-21@listserv.ieee.org
> >> >>>Subject: Re: [802.21] Tomorrow's Telecon material
> >> >>>
> >> >>>Qiaobing,
> >> >>>Without taking the discussion into classifying static or dynamic
> >> >>>information... are there any time-sensitive information
> >in our IE,
> >> >>>now?
> >> >>>
> >> >>>Regards,
> >> >>>Srini
> >> >>>
> >> >>>
> >> >>>>-----Original Message-----
> >> >>>>From: ext Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com]
> >> >>>>Sent: Friday, March 10, 2006 6:09 PM
> >> >>>>To: Sreemanthula Srinivas (Nokia-NRC/Dallas)
> >> >>>>Cc: STDS-802-21@listserv.ieee.org
> >> >>>>Subject: Re: [802.21] Tomorrow's Telecon material
> >> >>>>
> >> >>>>....
> >> >>>>
> >> >>>>>whether there is need for "timely delivery of IS" or not.
> >> >>>>
> >> >>>>The answer depends on what content the IS is carrying. If
> >> >the content
> >> >>>>is time sensitive, "yes", otherwise, "no".
> >> >>>>
> >> >>>>regards,
> >> >>>>-Qiaobing
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >
> >