Re: [DNA-BOF] AP5: cataloguing L2 Hints for DNA.

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Spencer,

Spencer Dawkins wrote:
> Dear Greg,
> 
> Not sure whether DNA wants to go down this path or not, but ...
> 
> The PILC working group was dorking with TCP over problematic links,
> and ended up chartered to work along two paths:
> 
> (a) what to do with the problematic links that were already deployed,
> and
> 
> (b) what advice to give designers of new links that would make them
> less problematic.
> 
> If DNA went the same way, there would also be two paths:
> 
> (c) what are deployed links capable of today, and
> 
> (d) what would IP, transport protocols, and/or application protocols
> like to know from new link technologies?
> 
> Examples from (d) might include:
> 
> (e) indication of nominal link bandwidth (so you can tell 802.11a from
> 802.11b without cheating) - transports/applications can't assume that
> the entire link bandwidth is available, but they CAN assume that they
> can't send 11 Mb/s over GPRS...
> 
> Would anyone else be interested in chasing (d) above?

I think that this sort of information would be
a nice to have feature fed into the network layer.

We have already seen one proposal to embed an
explicit link identity in the L2 frame (using
a global IPv6 prefix) in a draft.

draft-paultan-seamless-ipv6-handoff-802-00.txt

Things like this may make detecting network
attachment more straightforward.

I'm not sure about whether we in DNA would be
able to talk authoritatively about all kinds
of information elements though.

The point I was making to Daniel was about the
catalogue draft {your point (c)}, which was
discussed in the BoF.

We certainly have a role in engaging the link-layer
community to find ways in which we can make the
link-hint and network attachment detection tasks
easier.

Greg

> 
> Spencer
> 
> ----- Original Message ----- 
> From: "Greg Daley" <greg.daley@eng.monash.edu.au>
> To: "Soohong Daniel Park" <soohong.park@samsung.com>
> Cc: "'Alper Yegin'" <alper@docomolabs-usa.com>;
> <dna@eng.monash.edu.au>; "'Pyungsoo Kim'" <kimps@samsung.com>
> Sent: Wednesday, July 30, 2003 9:23 PM
> Subject: Re: [DNA-BOF] AP5: cataloguing L2 Hints for DNA.
> 
> 
> 
>>Hi Daniel,
>>
>>I've got two quick points.
>>
>>* we shouldn't be using the word trigger in the document
>>
>>* we're looking at existing procedures, which don't
>>   modify L2.
>>
>>Further work in the future which co-operates with
>>link-layer authorities may provide guidelines
>>for L2 systems.
>>
>>We have to see what we can get as hints today from
>>deployed systems.
>>
>>Greg
>>
>>
>>
>>Soohong Daniel Park wrote:
>>
>>>Hi all
>>>
>>>At this stage, I am wondering below issue can be discussed
>>>at DNA for L2 Hint issues.
>>>
>>>Could you let me know your view on this ?
>>>
>>>I am trying to write a brief mention as follows
>>>
>>>1. Problem statement
>>>
>>>The L2 trigger in WLAN might be based on the change between
>>>APs. But a change of AP on the same subnet does not require
>>>a change of AR since AR is L2 reachable from the MN connected
>>>to any APs. It should be required for the MN to know whether it
>>>changes AP or AR. However, in the existing mechanism, the MN
>>>could not know whether it changes AP or AR. Thus, when the MN
>>>changes AP without change of AR, there are some redundant
>>>traffics. These redundant traffics might be remarkable when there
>>>are many MNs that are now connecting to the PAR.
>>>
>>>2. Solution statement
>>>
>>>The beacon message given by AP is defined newly by adding the
>>>ARID (AR's Identity) to the reserved field. Other fields in the
>>
> beacon
> 
>>>messages are not affected since the existing reserved field is
>>
> used
> 
>>>for.
>>>
>>>
>>>
>>>Thanks in advance.
>>>
>>>
>>>Daniel (Soohong Daniel Park)
>>>Mobile Platform Lab,SAMSUNG Electronics
>>>
>>
>>
>