Subject: Re: [Seamoby] Examples of CAR discovery

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 31 Mar 2002 03:12:20

Hi:

As far as delegating QoS aspects of smooth handoff to NSIS is considered, 
the following statement that was discussed in the WG catches my attention 
when reading NSIS (rough) meeting minutes from IETF53.

[Quote:] "Regarding to the mobile IP, the hand of decision and trigger 
sources should be out of the scope of the NSIS. Thus the WG should rather 
focus only on "establishing" QoS after hand off."

The following statement from Mobile IP QoS requirements draft (WG document 
that has passed the last call) is interesting too:

[Quote:] "In this document, we assume that the target access router for
   MN's handover is already pinned down by other protocols. For
   example, Seamoby working group has started work on the candidate
   access router discovery protocols [3]. Thus, any QoS-capability
   specific negotiations that may affect the handover decision are
   outside the scope of QoS solution as such, rather need to be
   performed by candidate and target access router selection
   protocols."

BR,
Hemant

>From: "James Kempf" <[email-masked]>
>To: "Charlie Perkins" <[email-masked]>
>CC: <[email-masked]>
>Subject: Re: [Seamoby] Examples of CAR discovery
>Date: Fri, 29 Mar 2002 19:10:03 -0800
>
> > If one access router has 5 Mb/s available, and another only has
> > 10 Kb/s available, I would like to get my streaming video from
> > the first access router.  I might be able to have the choice.
> >
>
>Wouldn't it be better to let the IP QoS signaling protocol handle this?
>I believe this is exactly what NSIS is working on,
>but John Loughny could say more.
>
> > IP is exactly the right place for this to be disseminated, assuming
> > that we even have IP QoS in the first place.
>
>I was speaking of last hop link capacity. I agree that IP is the right
>place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS
>charter also speaks about last hop QoS signaling as well. There is some
>interest in NSIS to tie Layer 2 QoS and  IP QoS together on the last
>hop, but there has not yet been much work done on it.
>
> > I do not think
> > that this information would typically change much over the
> > 10-150 milliseconds that it "should" take to accomplish a
> > handover.  If this is a problem, though, one could define a
> > "special" kind of CAR discovery protocol that makes the
> > candidate access router reserve the bandwidth for 200 milliseconds,
> > or else not claim that it has the bandwidth available.
> >
>
>I did not mean just during the handover. If the information provided by
>the CAR discovery protocol has a lifetime of 200 msec, then if the total
>L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell
>during the time between when a mobile node gets its last CAR discovery
>update and when it decides to move to the cell. At that point, the QoS
>due to the new load may be below the decision point where the mobile
>node would want to move into the cell.
>
>                 jak
>
>
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Phil Neumiller" <[email-masked]>
Date: Sun, 31 Mar 2002 06:10:33 -0500

Interesting...
----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 31, 2002 3:12 AM
Subject: Re: [Seamoby] Examples of CAR discovery

> focus only on "establishing" QoS after hand off."

Don't know who this quote is from, but clearly this show a
mis-understanding.
There should be no "after" handoff.  A seamless handoff will not have a
before
and after.  A big part of QoS to mobiles is making the handoff seamless.

-pdn

---

From: "Phil Neumiller" <[email-masked]>
Date: Sun, 31 Mar 2002 06:10:33 -0500

Interesting...
----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 31, 2002 3:12 AM
Subject: Re: [Seamoby] Examples of CAR discovery

-pdn

---

From: "James Kempf" <[email-masked]>
Date: Sun, 31 Mar 2002 11:09:33 -0800

So it sounds to me like dynamic QoS negotiation for handover has fallen
between the cracks of the WGs.

Pat and I will take this point up with Allison. At this time, I would
rather not try to add it to our charter because we have a lot to do.
Having just jettisoned paging, I think we now have the right number of
tasks matched to people who have expressed interest in working on them.

            jak

----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 31, 2002 3:12 AM
Subject: Re: [Seamoby] Examples of CAR discovery

> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>

---

From: "James Kempf" <[email-masked]>
Date: Sun, 31 Mar 2002 11:09:33 -0800

jak

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 31 Mar 2002 13:09:34 -0800

Hello Jim,

I'd like to suggest that QoS handover is not the same as QoS negotiation.
For handover, we can assume that the service is authorized and that
there is a routing path available at least as far as the current access
router.  In the general case (e.g., NSIS(?)), these assumptions are not
valid.

Furthermore, having handovers that do not preserve some agreed-upon
bandwidth or delay parameters might be about as interesting as transport
in only the passenger side of the CAR.

Lastly, we have already some evidence that handing QoS from one
access router to another access router is about the same as handing
any other context between routers -- again, under the assumption that
the basic authorization has already been negotiated at some time in
the past.  There is no need to have two protocols where one is better,
regardless of political divisions within the IETF.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 31 Mar 2002 13:09:34 -0800

Hello Jim,

Regards,
Charlie P.

---

From: "Phil Neumiller" <[email-masked]>
Date: Sun, 31 Mar 2002 20:41:43 -0500

This seems pretty strange to me too Jim.  I hate to say it, but the IETF is
showing some
wireless ignorance here.  The MOST important thing SeaMoby could ever do in
the IETF is to facility seamless/smooth/soft/fluffy handoff.  This is an
ESSENTIAL
part of QoS.  I have not followed the NSIS mailing list, but it sounds
pretty misguided
to me.  What is SeaMoby chopped liver???

Thanks,

Phil

---

From: "Phil Neumiller" <[email-masked]>
Date: Sun, 31 Mar 2002 20:41:43 -0500

Thanks,

Phil

---

From: John Schnizlein <[email-masked]>
Date: Sun, 31 Mar 2002 20:46:06 -0500

At 08:41 PM 3/31/2002, Phil Neumiller wrote:
>...  What is SeaMoby chopped liver???

Please keep up .. "What [is SeaMoby] a potted plant?"

What do you expect on Easter evening?

John

---

From: John Schnizlein <[email-masked]>
Date: Sun, 31 Mar 2002 20:46:06 -0500

John

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Sun, 31 Mar 2002 21:02:35 -0500

NSIS has a very strong mobility dimension to it, 
which I find very interesting, but odd.

And, I agree, completing handoff quickly with 
optional low loss support is the first order 
mobile QOS.

Second order, is much harder. It requires a good 
model of resources in the network and how to
allocate/re-allocate or engineer them in 
support of tighter QOS contol (delay, bandwidth). 

But as we see, with all QOS initiatives in IETF 
there is a lot of activity and out put 
but incentives for carriers to deploy it. 

Its just a very hard problem. Question is why
do you need QOS signaling when the network 
has no QOS? 

You certainly need some signaling for handoff.

---
Andrew
http://comet.columbia.edu/~campbell

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Phil Neumiller
> Sent: Sunday, March 31, 2002 8:42 PM
> To: Charlie Perkins; James Kempf
> Cc: Hemant Chaskar; [email-masked]
> > > > sources should be out of the scope of the NSIS. Thus 
> the WG should
> > > rather
> > > > The following statement from Mobile IP QoS requirements 
> draft (WG
> > > document
> > > > [Quote:] "In this document, we assume that the target 
> access router
> > > for
> > > > >Wouldn't it be better to let the IP QoS signaling 
> protocol handle
> > > this?
> > > > >I was speaking of last hop link capacity. I agree that 
> IP is the
> > > right
> > > > >place to handle next to last hop QoS (i.e. DiffServ). 
> I believe the
> > > NSIS
> > > > >charter also speaks about last hop QoS signaling as 
> well. There is
> > > some
> > > > >I did not mean just during the handover. If the 
> information provided
> > > by
> > > > >the CAR discovery protocol has a lifetime of 200 msec, 
> then if the
> > > total
> > > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could 
> move into the
> > > cell
> > > > >update and when it decides to move to the cell. At 
> that point, the
> > > QoS

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Sun, 31 Mar 2002 21:02:35 -0500

---
Andrew

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 31 Mar 2002 18:43:33 -0800

Hello Andrew,

> optional low loss support is the first order

What does "loss" mean?

> support of tighter QOS contol (delay, bandwidth).

Maybe not!  If we have a good "discovery"
protocol, and we have suboptions to say what
it is that we want to discover from possibly
neighboring access points, then we can leave it
for later to define the data formats for the suboptions.

Furthermore, any other strategy which
commingles data and control flow is, in my
opinion, headed towards failure.

> but incentives for carriers to deploy it.

I could not parse this!  Is there a "no" before
"incentives"?

> do you need QOS signaling when the network

If "the network" has no QoS, then it cannot satisfy
any request which mandates it.  That's clear.
If a request is preferential for appropriate QoS
but does not mandate it, then the rules have to make
it clear when the CAR discovery can still succeed
if there is no QoS to satisfy the preferential request.

Maybe the participants in this discussion would agree
that we cannot boil the QoS ocean, but I wish we
could still make a localized protocol that does a small
*but essential* job -- and it's a job for [seamoby],
in my opinion.

> You certainly need some signaling for handoff.

Agreed!

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 31 Mar 2002 18:43:33 -0800

Hello Andrew,

What does "loss" mean?

Agreed!

Regards,
Charlie P.