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

[Spencer Dawkins <spencer@mcsr-labs.org>]

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?

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
> >
>
>