Subject: RE: [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)

From: [email-masked]
Date: Tue, 18 Oct 2005 16:43:56 -0700

Colleagues,

The folks from the IETF have been saying that the IS consuming more
bandwidth is not a problem, while the IEEE folks are saying bandwidth
and latency are key concerns. We need some meeting of the minds and
implementations/empirical data to help out here.

Best Regards,
Michael
 
-----Original Message-----
From: ext Qiaobing Xie [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2005 3:11 PM
To: [email-masked]
Subject: Re: [Mipshop] Re: Architectural Considerations for Handover
InformationServices (was: Re: CARD Discussion Query Discussion)

Yoshihiro Ohba wrote:
...
> - In reality, 3GPP2 has XML-based method (e.g., XCAP) in its 
> dependency list.

If I remember it right XCAP/XML is used there for maintaining the
address book/buddy list that sort of things. I can imagine that sort of
events only happen at most no more than a few times a day for any given
user and probably only happen when the user is NOT in a call. In
contrast, IS query/response likely will be part of the h/o call flow...

regards,
-Qiaobing

> Yoshihiro Ohba

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 19 Oct 2005 09:42:08 -0500

Michael,

I know there are places where xml is involved in call control, e.g., an 
optional xml document can be embedded in a SIP invite message in some 
PoC VoIP call control messages in OMA. However, all 
implementations/empirical data that I am aware of points to that as the 
cause of a major portion of the call setup delay of PoC (~5-9 sec as 
reported). It is widely recognized that is a penalty we all are paying 
for the extensibility, flexibility, and text-based nature of SIP/XML 
call control signaling and tremendous effort and resources have been 
spent to reduce the VoIP call setup latency across the industry. 
Fortunately, that only happens once at the setup of a call (I am not 
aware of any significant SIP/XML signaling used mid-session).

In my view, handoff is much more time sensitive than the call setup from 
a user's perspective and handoff can happen repeatedly in a call. Making 
XML handling part of the handoff procedure may not be a good idea at all.

regards,
-Qiaobing

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Oct 2005 09:42:30 -0700

Michael,

I don't believe that IETF is really saying that bandwidth and latency are 
not problems, to the extent that one can say that "IETF" has an opinion. :-)

My own view is that bandwidth and latency are second order problems that are 
easily solvable using a compact information representation format. XML is 
not such a format. Binary TLV is. I was involved in both the FMIP and CARD 
work, and I think this is something they got right. Text format isn't 
appropriate at a system level. So the real issue is "what is the approprate 
representation format for IS services"?

The analogy with SIP may be confusing. The reason text format is used in SIP 
is historical. SIP evolved out of SNMP. Text format makes sense with SNMP 
because the content of the messages is email. It doesn't make much sense 
technically with SIP because it is a control protocol. None of the 
traditional telephony control protocols, such as IS-41, use text format. The 
only technical argument one could I suppose make for text for SIP is that it 
makes debugging easier, but with a good protocol dump facility, like 
ethereal, this is really a nonissue.

That said, the NEighborhood Discovery Protocol (NED, 
draft-kempf-mipshop-nhood-discovery-00.txt) that Rajeev Koodli and I are 
designing as a container protocol for IS, leaves the representation 
completely up to the definition of the information types. So if 802.21 
decides it wants to use XML, the link information types for NED can be 
defined that way, and, at the same time, NED can be used to transport TLV 
defined link information for IETF protocols such as FMIP.

            jak

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 18, 2005 4:43 PM
Subject: RE: [Mipshop] Re: Architectural Considerations for 
HandoverInformationServices (was: Re: CARD Discussion Query Discussion)

Colleagues,

Best Regards,
Michael

-----Original Message-----
From: ext Qiaobing Xie [mailto:[email-masked]]
Sent: Tuesday, October 18, 2005 3:11 PM
To: [email-masked]
Subject: Re: [Mipshop] Re: Architectural Considerations for Handover

Yoshihiro Ohba wrote:
...

regards,
-Qiaobing

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Oct 2005 11:57:26 -0400

Qiaobing,

Could you elaborate on the "major portion"?  Do you mean the major portion 
is 5 to 9 sec, or the major portion is a part of 5 to 9 sec?

Also, which is more dominant delay factor in SIP/XML signaling,
transferring text over the air (transmission delay) or processing text
on cellular phones (processing delay)?

In terms of the sensitivity of IS, as long as IS can be executed
between handovers and in the middle of the call and in the background
without disrupting the call, the delay requirement of IS is not
necessarily much more sensitive than the call setup time, in my
opinion.

Yoshihiro Ohba

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 19 Oct 2005 14:33:50 -0400

I also  agree that  if IS  can be done  proactively before  the actual
handoff as  a background  process in order  to obtain  the neighboring
network information (this is how it should be done in any case) , this
querying/processing delay should not affect the handoff performance.

But  of  course  based  on  expected delay  associated  with  the  XML
query/response processing,  IS procedure needs to be  started ahead of
time before one  goes out of the current  coverage completely. This is
more important for a fast-moving vehicle for example.

Thanks
Ashutosh

> > >contrast, IS query/response likely will be part of the h/o call flow...

Ashutosh

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 19 Oct 2005 15:01:12 -0500

> is 5 to 9 sec, or the major portion is a part of 5 to 9 sec?

A "major portion" of the overall 5 to 9 sec, but there is no general way
to precisely measure it (see below).

> on cellular phones (processing delay)?

Both are major - which one is more dominant depends on the particular
design and platform. Transferring text SIP over the air for call control
is unacceptable, this is why both 3GPP and 3GPP2 are critically counting
on rohc/sigcomp from IETF to compress the SIP messages before it goes
over the air. It is a *big* effort for several years (a look in
rohc/sigcomp can tell). The sigcomp compressor/decompressor is
complicated and CPU intensive and is dictionary based. The achievable
compression ratio for SIP still leaves a lot to be desired, and I don't
know whether it can do anything good for embedded XML documents. At the
same time, the processing delay due to the compression/decompression
algorithm is a common issue for most small device design due to their
limited computing power. This hasn't take into account the processing
time for XML handling itself.

> necessarily much more sensitive than the call setup time, in my

Unfortunately, most handoffs are not predictable, i.e., they depends on
how a UE moves, for example, when a UE moves into a new unfamiliar
network and urgently wants to make a h/o decision, the IS becomes the
most needed! If IS can only satisfy the UE during time insensitive
periods, its usefulness will be severely limited, IMO.

regards,
-Qiaobing