Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

AW: [802.21] Tomorrow's Telecon material



Hello Together,

I think we already have such information field in our MIHF
protocol. If the local MIHF needs a quick response then we
can also set the ACK req. bit. This is irrespecitive of
transport protocol and at MIHF level.

But if we want to put a requirement on transport protocol,
the thing which is not clear to me is, how MIHF can tell this
to  the transport protocol on the fly. My question is, are
we also having extra information other than MIHF frame (hdr+payload)
given to transport protocol?

Regards,
Kalyan

-----Ursprüngliche Nachricht-----
Von: Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM] 
Gesendet: Freitag, 17. März 2006 00:46
An: STDS-802-21@listserv.ieee.org
Betreff: 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
>>>>
>>>>
>>>
>> 
>