Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

From: "Gary Kenward" <[email-masked]>
Date: Fri, 5 Jul 2002 11:32:46 -0400

Robert:
 
  I will have to read Cedric's draft. I wasn't aware that it discussed CT.
With deference to Cedric, and what I am sure is a thoughtful
analysis, it seems to me that understanding the relationship between CT and
NSIS would require, at the very least, a CT solution, or
something close to a CT solution. Clearly there is a difference of opinion
as to what CT should be (the requirements draft is apparently
going to go through another revision, so who knows?).
 
  In my view, if CT is in place, then NSIS should not be invoked as a result
of a handover. A pretty simple relationship. The only exception
that I can imagine is if there is some impact on a service that is not
provided at an ANR (i.e. an AR or an internal router), then NSIS may
be required to maintain that service. However, I could not name this service
at this point.

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: July 5, 2002 10:59
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]';
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra
ft-westphal-nsis-qos-mobileip-00.txt)

hi gary,
 
my comments are purely on draft-westphal-nsis-qos-mobileip and associated
email discussions (since that's been the only input I have seen recently
which explicitly discusses the relationship between CT and NSIS, and which I
had worries about). 
in particular, any comments I make about MN-AR signalling are really to
emphasise the difference between the cases of
a) not having CT signalling that carries QoS information MN-AR (if there is
or isn't other CT signalling I don't really care), and
b) having CT signalling that does carry QoS information MN-AR, which seems
to be the assumption of the mentioned draft.
 
our recent framework activities assumed (a). if you're saying that the
seamoby w.g. requirements also impose (a), that's fine by me. i also don't
want to re-open old discussions (certainly not on the nsis list, anyway).
 
i suspect we're basically in agreement about NSIS/CT relationships: after a
handover, if CT happened, it should be possible to have less NSIS signalling
on the on-path segment which goes over the air.
 
cheers,
 
robert h.
 
PS referring to a previous email, i think the view that NSIS is "likely to
be of limited use in mobility situations" is rather pessimistic. i would
rather say that if you want the resources signalled for by NSIS to be
available seamlessly over handovers, you'll need something else as well,
which could be CT. the basic point seems to be that NSIS shouldn't try to
solve the cross-path context/state transfer problem - any more than CT
should try to solve the along-path context/state establishment problem. 
[gwk] I agree. I was not trying to be as much pessimistic, as I was pushing
back against this concept that NSIS + LMM => Seamless Mobility. To be more
precise,
if it takes longer then a few 10s of ms to set up the new, conditioned path,
then the handover will likely not be seamless in 3G. Signalling,
particularly over the 
air (again, 3G), takes relatively significant amount of time to complete.
10s of ms is a rough approximation, but if you are running voice frames,
more then, say 
20ms of additional handover delay will start  impinging on the service
requirements for the voice - i.e. either frames have to be dropped or
delayed beyond 
the performance constraint. It is difficult to pin down these numbers,
particularly in an IETF email list, but any delay budget analysis that I
have seen usually 
yields numbers in the stated range (keep in mind that delay/drop allowances
have to be budgeted for other components of the access network and for the
link layer handover).
 
NSIS + LMM (or some variant of MIP) might be one approach to mobility. Fine,
but given what I understand about what NSIS is, and is not, it can never be
any where near as seamless as a solution that incorporates CT. Is CT simply
an "optimization" - well, that depends on how much service disruption the
user
can tolerate. Usually, there is a threshold where the service is simply
considered unusable.
 
Cheers,
Gary

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 08 Jul 2002 10:28:15 +0200

>   In my view, if CT is in place, then NSIS should not be invoked as a
> result of a handover. A pretty simple relationship. The only exception
> provided at an ANR (i.e. an AR or an internal router), then NSIS may  be
> required to maintain that service. However, I could not name this service
> at this point.

I don't see how CT can work without NSIS in the general case. If all your 
AR are connected to the swame next hop router, it may work. Generally, you 
might need to signal to the far end after handover.

Marcus

> [email-masked] Cc: [email-masked];
> [email-masked]; [email-masked]'
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
> hi gary,
>
> which explicitly discusses the relationship between CT and NSIS, and
> which I had worries about).  in particular, any comments I make about
> MN-AR signalling are really to emphasise the difference between the cases
> of  a) not having CT signalling that carries QoS information MN-AR (if
> there is or isn't other CT signalling I don't really care), and  b)
> having CT signalling that does carry QoS information MN-AR, which seems
> seamoby w.g. requirements also impose (a), that's fine by me. i also
> don't want to re-open old discussions (certainly not on the nsis list,
> anyway).
> i suspect we're basically in agreement about NSIS/CT relationships: after
> a handover, if CT happened, it should be possible to have less NSIS
> signalling on the on-path segment which goes over the air.
> cheers,
>
> robert h.
>
> PS referring to a previous email, i think the view that NSIS is "likely
> to be of limited use in mobility situations" is rather pessimistic. i
> would rather say that if you want the resources signalled for by NSIS to
> be available seamlessly over handovers, you'll need something else as
> well, which could be CT. the basic point seems to be that NSIS shouldn't
> try to solve the cross-path context/state transfer problem - any more
> than CT should try to solve the along-path context/state establishment
> problem.  [gwk] I agree. I was not trying to be as much pessimistic, as I
> was pushing back against this concept that NSIS + LMM => Seamless
> Mobility. To be more precise,  if it takes longer then a few 10s of ms to
> set up the new, conditioned path, then the handover will likely not be
> seamless in 3G. Signalling, particularly over the  air (again, 3G), takes
> relatively significant amount of time to complete. 10s of ms is a rough
> approximation, but if you are running voice frames, more then, say  20ms
> of additional handover delay will start  impinging on the service
> delayed beyond  the performance constraint. It is difficult to pin down
> these numbers, particularly in an IETF email list, but any delay budget
> analysis that I have seen usually  yields numbers in the stated range
> (keep in mind that delay/drop allowances have to be budgeted for other
> components of the access network and for the  link layer handover).
>
> NSIS + LMM (or some variant of MIP) might be one approach to mobility.
> Fine, but given what I understand about what NSIS is, and is not, it can
> never be  any where near as seamless as a solution that incorporates CT.
> Is CT simply an "optimization" - well, that depends on how much service
> disruption the user  can tolerate. Usually, there is a threshold where
> the service is simply considered unusable.
> Cheers,
> Gary
>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Jul 2002 07:15:41 -0700

Hello Gary,

I have a comment on another point in your earlier message.

Gary Kenward wrote:

> result of a handover.

Suppose a handover has occurred, and some QoS has been negotiated
via CT between two access routers to support the mobile node at the new
access routers.  This could involve having the new router making sure
it has sufficient capacity to support the mobile device, and making sure

that the tunnel between the two routers can be managed with small
enough delay.

Then, after the handover is complete, it might be better to renegotiate
QoS so that the previous access router no longer was required to
maintain the excess capacity needed to serve the tunnel to the new
access router.  This could involve signaling so that packets are
routed directly to the new access router, presumably with some QoS
negotiation.  This could involve NSIS.

Thus, I don't agree with your statement above.  But I am willing to
agree
that CT should not necessarily be intertwined with NSIS.

Regards,
Charlie P.