Subject: [Seamoby] 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 10:34:34 -0400

Robert:

  In your discussion of CT, you are presupposing a wg solution
for CT that does not exist. The work on the CT protocol has not begun
in Seamoby. Indeed, if you examine the CT requirements,
signalling from the MN to the access network is prohibited. The
reason being is that the sole purpose of CT is to enable a fast, smooth,
seamless handover. Signalling over the air simply takes too much time,
and the value of signalling from MN to AR has never been clearly identified.

  This issue was debated extensively in the CT design group and on
the Seamoby list. I understand that there are people who feel otherwise,
and please, let's not regurgitate the arguments here. As the requirements
currently stand, CT is an AR to AR protocol.

  One source of confusion might be the work on the discovery protocol.
It is my, admittedly minority opinion, that the use of MN to AR signalling
to perform CT was moved into the discovery solution. And again, nothing
can be done between the MN and an AR that cannot be done more efficiently,
and faster, between two ARs. 

  The way I see the directions of the two solutions lining up so far,
NSIS and CT have little interaction. NSIS could be invoked if a CT attempt
fails, but the restriction to have NSIS along the path implies that some
path must exist before NSIS can be invoked. Thus, NSIS can be used only
*after* a handover has completed, and thus there is no opportunity for 
interaction. Of course, all of this depends on what you define as a "path"
- I am assuming that it is the IP forwarding path for the MNs bearer
traffic.

gary

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: July 5, 2002 05:35
> To: [email-masked]'; [email-masked];
> [email-masked]; [email-masked]
> Cc: [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 all,
> 
> I don't think there's any disagreement that CT is a tool that 
> NSIS could use (as an optimisation).
> 
> What's entirely unclear to me is what sort of tool CT is: is 
> it a hammer or a screwdriver or a combination of the two? I 
> guess this is more a question for the seamoby people, but we 
> need to know the answer to know how to use it.
> 
> More formally, there seem to be two extremes:
> 
> a) NSIS is used for MN-AR resource (QoS) signalling, and 
> AR-rest of world signalling; CT can be used to transfer state 
> (both resource state and NSIS protocol state) between ARs at 
> handover, but if this involves any MN-AR messages (e.g. CTIN) 
> they aren't QoS related. NSIS-CT interaction can occur at the 
> ARs to do state transfer at handover time.
> 
> b) CT messages (e.g. CIN) can be used by the MN to set up QoS 
> context in the AR, which it can then later transfer to a new 
> AR. NSIS is used to signal QoS for AR-rest of network. 
> NSIS-CT interaction takes place at the AR to interwork flow 
> setup and resource descriptions, and this interaction takes 
> place at flow setup time. (Essentially, CT provides a QoS 
> signalling protocol for the edge of the network, which NSIS 
> would have to interwork with, in the same way that it has to 
> interwork with RSVP/Intserv.)
> 
> our framework draft-hancock-nsis-fw-00.txt basically assumes (a).
> this draft-westphal-nsis-qos-mobileip-00.txt basically 
> assumes (b) so far as I can tell.
> 
> I'm not trying to argue which of (a) or (b) is 'correct' at 
> this stage, just establish that they are not the same. (And 
> so we probably have to make a choice, although I suppose you 
> could allow both models...)
> 
> Cheers,
> 
> Robert H.
> 
> > -----Original Message-----
> > From: Marcus Brunner [mailto:[email-masked]]
> > Sent: 05 July 2002 10:05
> > To: [email-masked]; Hancock, Robert; [email-masked];
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: 
> Comments on
> > draft-westphal-nsis-qos-mobileip-00.txt)
> > 
> > 
> > I see CT as an optimization only and not required for NSIS. 
> > However, since 
> > there is a tendency to support only on-path signaling, this 
> > would not work 
> > anyway (because CT would need off-path signaling for at least 
> > some time).
> > 
> > Marcus
> > 
> > --On Donnerstag, 4. Juli 2002 11:33 +0300 
> > [email-masked] wrote:
> > 
> > > Hi Robert,
> > >
> > >> On the 'edge signalling' case, I guess the main point is that
> > >> I'm confused about the scope of seamoby CT. Specifically
> > >> regarding MN-AR signalling (no issue about the AR-AR part):
> > >
> > > From my viewpoint, CT is not required for NSIS. I view CT as
> > > one tool that an NSIS solution could use.  So, I definately think
> > > that at some point, we will need some sort of applicability
> > > statement describing how to use CT for NSIS.
> > >
> > > John
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > 
> > 
> > --------------------------------------
> > 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
> > 
> > 
> ==============================================================
> ==========================
> Permission is hereby granted to pass the contents of this 
> communication to third parties and any restrictions regarding 
> confidentiality do not apply.
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 5 Jul 2002 10:34:34 -0400

Robert:

gary

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 5 Jul 2002 15:58:53 +0100

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. 

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: 05 July 2002 15:35
To: Hancock, Robert; [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)

Robert: 

- I am assuming that it is the IP forwarding path for the MNs bearer traffic. 

gary 

> From: Hancock, Robert [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: July 5, 2002 05:35 
> > From: Marcus Brunner [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > Sent: 05 July 2002 10:05 
> > > https://www1.ietf.org/mailman/listinfo/nsis <https://www1.ietf.org/mailman/listinfo/nsis>  
> > 
> > 
> > 
> > WWW:    http://www.ccrle.nec.de/ <http://www.ccrle.nec.de/>  
> > personal home page: http://www.brubers.org/marcus <http://www.brubers.org/marcus>  
> > 
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 5 Jul 2002 15:58:53 +0100

hi gary,

 
 
cheers,
 
robert h.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: 05 July 2002 15:35
To: Hancock, Robert; [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)

Robert: 

gary

---

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: "Gary Kenward" <[email-masked]>
Date: Mon, 8 Jul 2002 10:55:25 -0400

Marcus:

  If I understand your comment, I believe there are two responses:
first, CT need not be confined to context transfers between ARs,
although this is definitely the most straightforward application of CT; 
second, and probably most important, there are access network solutions 
that do not require services to be established at the IR on a per flow 
basis - the per flow management happens only at the edges.

  It is worth noting that if NSIS *is* required to negotiate services
between
the MN and any ANR for every handover, then CT is not needed (if an IR must
be 
signalled from the MN, then the AR will receive the signalling first; if ARs
are signalling each other using NSIS, then why bother with CT?). 

  I emphasize, again, that building signalling into each and every
handover, particularly at the IP layer, is not conducive to seamless
handover. It is very difficult to make a case for this assertion without
discussing numbers - hopefully it is enough to observe that any exchange
of information between the MN and the AN during or after a handover has
a great potential for disrupting the service, particularly if resource
allocations are delayed. 

  I am not sure of what you mean by the "far end": are you suggesting
end-to-
end signalling with each handover? Or, by far end do you mean the AN to
core network edge? If so for what purpose? Is there an edge based approach 
that would eliminated the need for access edge to "far edge" signalling 
with each handover?

Regards,
Gary

> Sent: July 8, 2002 04:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert';
> >   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]'
> > 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
> >
> 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 8 Jul 2002 10:55:25 -0400

Marcus:

Regards,
Gary