Subject: [NEXTEL-1] P2P and stack issues...

From: "Juliet" <[email-masked]>
Date: Sat, 23 Nov 2002 20:14:01 -0000

An additional opinion mixed in too...

On Fri, 22 November 2002, "Mike " wrote:
> 
> <html><body>
> <tt>
> My comments mixed in below. <BR>
> <BR>
> &gt; My interpretation is the same - the HCI buffers are just a<BR>
> &gt; hardware interface and not related to individual connections, 
etc.<BR>
> &gt; In a situation where the number of connections may vary and 
run<BR>
> &gt; at different data rates, it would not make sense to allocate 
HCI<BR>
> &gt; buffers per connection.<BR>
> <BR>
> Cool.&nbsp; At least I think I am on a right track here. <BR>
> <BR>

The interface specific connections, which are available to establish 
over a direct wireless link, depends strongly to hardware devices, 
and the OS framework of thy, definitely. 
Established links among devices are undoubtly running in different 
speed, capable of different data rates depending assets involved, 
especially in MANET configurations (and thats what its about I 
guess). 
I do not agree that in common cases (not explicitely case studies!) a 
lot of different connections are established at all. Most will just 
access various (or location- specific just the next) LAN APs, but not 
in combination with a lot of different other devices in the same ad- 
hoc network. 

> &gt; The comment I wanted to add was with respect to the 
discussion<BR>
> &gt; on using a semaphore to allocate the buffers as a resource. 
One<BR>
> &gt; problem I found was handling the problem of the other end 
&quot;dropping<BR>
> &gt; off&quot;. In this situation, the Disconnection Complete event 
occurs<BR>
> &gt; but there is *no* Completed Packets event - the spec says 
the<BR>
> &gt; host &quot;must assume they have been flushed&quot;. <BR>

The semaphore issue I can not really identify properly in that 
context, the mutual exclusive channels in terms of unestablished or 
established ones ? Established channels are flushed before any 
completed packets event, what shall that mean ? If someone moves from 
one picocell area to the next, the links have to be re- located with 
the CoA, to keep the connection active. But why are "they" flushed ? 

> <BR>
> Hmm, If I remember correctly I believe (at least on the SiW 
paltform)<BR>
> that the embedded stack tracked this and sent me a 
&quot;completed_packets&quot;<BR>
> event for the corresponding handle.&nbsp; If my memory serves me 
correctly <BR>
> then my semaphore implementation is still valid. <BR>
> &gt; Well, stacks don't &quot;make assumptions&quot; which lead to 
some kludgy <BR>
> &gt; code to handle something that occurs very rarely. I really 
consider <BR>
> &gt; this to be a serious architectural flaw in the HCI design, but 
hey, <BR>
> &gt; I'm a little late to complain.<BR>

About the Bluetooth stack, yes we are years too late to complain 
about what other people specified, but hey there are absolut new 
stacks possible to specifiy if there is any better idea available... 
else the scheme can lead to enhancement specification or extension/ 
migration- layers of the stack towards other wireless 
technology...rather than RFcomm ( :) ?!)

> However, that is one interpretation (my previous comment).&nbsp; I 
don't <BR>
> know that other stacks (LM in particular) perform the same way. <BR>
> At this point I am thinking that LM must track outstanding packets 
<BR>
> for a given Connection Handle and such if a Handle becomes invalid 
<BR>
> because of a disconnection then it is likely that a 
completed_packets <BR>
> event should be sent to clear all of the buffers for that handle. 
<BR>
> Like you said though it definitely is not clear who must do 
what.&nbsp; I <BR>
> would think that the LM should ensure that:<BR>
> A. Its resources are freed<BR>
> B. It informs upper layers that resources were freed<BR>

Why ? What are the intentions behind that ?

> &gt; To deal with this, I found that after the semaphore was 
waited<BR>
> &gt; to allocate an HCI buffer, it was also necessary to 
maintain<BR>
> &gt; an additional per handle count just in case a disconnect<BR>
> &gt; occured on the handle. If the disconnect occured, the 
semaphore<BR>
> &gt; needs to be posted to reclaim the buffers because the<BR>
> &gt; Completed Packets event does not occur. <BR>
> <BR>
> I think that to do this would be assuming that LM cleared the 
buffers <BR>
> and I would really prefer only to report and act upon whatever LM 
<BR>
> tells me to.&nbsp; Hopefully some of these will be cleared up by 
the HCI <BR>
> working group? <BR>

Seems so, yes, that LM suggerated some misguidance, whatoever LM, 
seems to be device specific too. The HCI working group... hm. 

>  <BR>
> &gt; I guess I should add that my environment assumes multiple <BR>
> &gt; connections to multiple devices whereas a point-to-point <BR>
> &gt; stack could easily just reset the semaphore each time the<BR>
> &gt; connection goes down.<BR>
The ability for point to point connections are just among 
establishable links, not devices in parked mode or devices out of 
sight. Yes that might be a daily reconfiguration task of course (a 
collection of semaphores beside collaborating LAN APs and P2P). Seems 
to be the broadband issue, really. 

> My implementation doesn't necessarily assume anything.&nbsp; It is 
<BR>
> entirely event driven and only acts when someone calls something or 
<BR>
> the underlying stack sends me an event.&nbsp; That way I can be p2p 
or <BR>
> p2mp or whatever it happens to become.<BR>
> <BR>
Yes, thats really strange, especially if connections are never 
established fully to exchange data, just tried initial TLP message 
broadcasted, sequence numbers, but no link establishment to be 
available. Strange devices or strange stack implementation of the LM 
(whatoever that might be).

> &gt; Do you have any better ideas on this?<BR>
> <BR>
> Unfortuneately, I do not.&nbsp; Thats kind of why I brought it up 
again. <BR>
> Buffer management at HCI seems a little sketchy and should probably 
<BR>
> be clarified in the next revision for HCI.&nbsp; Don't know when 
that will <BR>
> be.&nbsp; Maybe someone attending the next unplugfest can have it 
ruled <BR>
> on? That is what brought about many changes and errata.<BR>
> I just wanted a sanity check on my implementation. <BR>
> Mike<BR>
> <BR>
> </tt>
> 
> <br>
> 
> <!-- |**|begin egp html banner|**| -->
> 
> <table border=0 cellspacing=0 cellpadding=2>
> <tr bgcolor=#FFFFCC>
> <td align=center><font size="-1" color=#003399><b>Yahoo! Groups 
Sponsor</b></font></td>
> </tr>
> <tr bgcolor=#FFFFFF>
> <td align=center width=470><table border=0 cellpadding=0 
cellspacing=0> <tr> <td align=center><font face=arial size=-
2>ADVERTISEMENT</font><br><a 
href="http://rd.yahoo.com/M=234081.2677558.4057087.1925585/D=egroupweb
/S=1707367878:HM/A=1327986/R=0/*http://ad.doubleclick.net/clk;4870027;
7586687;a?http://www.ameriquestmortgage.com/welcome.html?
ad=Yahoo01"><img 
src="http://us.a1.yimg.com/us.yimg.com/a/am/ameriquest/yahoo_300x250_f
iles.gif" alt="" width="300" height="250" 
border="0"></a></td></tr></table></td>
> </tr>
> <tr><td><img alt="" width=1 height=1 
src="http://us.adserver.yahoo.com/l?
M=234081.2677558.4057087.1925585/D=egroupmail/S=:HM/A=1327986/rand=804
654710"></td></tr>
> </table>
> 
> <!-- |**|end egp html banner|**| -->
> 
> 
> <br>
> <tt>
> To maintain your subscription, go to:<BR>
> <BR>
> <a 
href="http://groups.yahoo.com/group/bluetooth">http://groups.yahoo.com
/group/bluetooth</a></tt>
> <br>
> 
> <br>
> <tt>Your use of Yahoo! Groups is subject to the <a 
href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of 
Service</a>.</tt>
> </br>
> </body></html>

------------------------ Yahoo! Groups Sponsor ---------------------~-->
·FREE Health Insurance Quotes-eHealthInsurance.com
http://us.click.yahoo.com/1.voSB/RnFFAA/46VHAA/61FxlB/TM
---------------------------------------------------------------------~->

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/