Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18224 for ; Mon, 8 Jul 2002 11:02:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22269; Mon, 8 Jul 2002 10:58:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22116 for ; Mon, 8 Jul 2002 10:58:19 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17918; Mon, 8 Jul 2002 10:57:25 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68EtxI11578; Mon, 8 Jul 2002 10:55:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 10:55:58 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BEA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , "'Hancock, Robert'" , john.loughney@nokia.com, cedric@iprg.nokia.com, erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org, Hemant.Chaskar@nokia.com, "'seamoby@ietf.org'" Date: Mon, 8 Jul 2002 10:55:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2268F.7DD7EA5A" Subject: [Seamoby] RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/plain; charset="iso-8859-1" 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 > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: July 8, 2002 04:28 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert'; > john.loughney@nokia.com; cedric@iprg.nokia.com; > erafodo@ESEALNT448.al.sw.ericsson.se > Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on > dra ft-westphal-nsis-qos-mobileip-00.txt) > > > > > > 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. > > 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 > > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: July 5, 2002 10:59 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; > > john.loughney@nokia.com; cedric@iprg.nokia.com; > > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org; > > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org' > > 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 > > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > ------_=_NextPart_001_01C2268F.7DD7EA5A Content-Type: text/html; charset="iso-8859-1" RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on dra ft-westphal-nsis-qos-mobileip-00.txt)

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

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: July 8, 2002 04:28
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Hancock, Robert';
> john.loughney@nokia.com; cedric@iprg.nokia.com;
> erafodo@ESEALNT448.al.sw.ericsson.se
> Cc: nsis@ietf.org; Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> Subject: RE: what is edge signalling? (was: RE: [NSIS] Re: Comments on
> dra ft-westphal-nsis-qos-mobileip-00.txt)
>
>
>
>
> >   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.
>
> 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
>
> >
> >
> > -----Original Message-----
> > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> > Sent: July 5, 2002 10:59
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de';
> > john.loughney@nokia.com; cedric@iprg.nokia.com;
> > erafodo@ESEALNT448.al.sw.ericsson.se Cc: nsis@ietf.org;
> > Hemant.Chaskar@nokia.com; 'seamoby@ietf.org'
> > 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
> >
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>

------_=_NextPart_001_01C2268F.7DD7EA5A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby