Subject: [Mipshop] Containers and not content for handover information services

From: Greg Daley <[email-masked]>
Date: Tue, 18 Oct 2005 13:37:53 +1000

Hi,

I'm writing to express my dismay about the seeming over concern
of people about the formatting for content which would be
exchanged over an information service.  At this stage, I think
we need to assume that the handover information is opaque to us
as designers of the transmission mechanism, so that we don't
get distracted by details.

There are bigger issues than whether the message formats
will contain TLV or XML information.  In fact, I can only
see three ways that the content formatting itself will
affect the delivery of handover information service
messages over IP.

1) Sequencing and Fragmentation:
    There needs to be message (and message fragment)
    identification.

    It could be possible to avoid these in the messages
    themselves with a particular encoding, but I guess
    it's premature to optimize this

2) Congestion control:

    One system may have higher overheads than another
    which may cause different rate limitation to be required.

3) Resource Control:

    Processing resources may be consumed with a particular
    encoding (perhaps more than another).

    This may encourage identification of the mobile in order
    to limit resource consumption on a per-node basis.

These aren't really big problems, compared to:

What message exchanges are needed for IS?

What discovery mechanisms can we assume?

Is it necessary to have IS servers > 1 hop away?

What level of trust is required for IS servers?

Is the communication datagram oriented or stream oriented?

Looking too deeply into the content means that the big questions
are likely to be obscured, compared to more fundamental ones,
which will affect sequencing, congestion and resource control
anyway...

Would anyone like to work on the big picture?

I'd love to help out where I can.

Greg

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Oct 2005 15:05:32 +0200

Greg Daley wrote:

> Hi,
> 
> I'm writing to express my dismay about the seeming over concern of
> people about the formatting for content which would be exchanged over
> an information service.  At this stage, I think we need to assume
> that the handover information is opaque to us as designers of the
> transmission mechanism, so that we don't get distracted by details.
> 
> There are bigger issues than whether the message formats will contain
> TLV or XML information.  In fact, I can only see three ways that the
> content formatting itself will affect the delivery of handover
> information service messages over IP.
> 
> 
> 1) Sequencing and Fragmentation: There needs to be message (and
> message fragment) identification.
> 
> It could be possible to avoid these in the messages themselves with a
> particular encoding, but I guess it's premature to optimize this
> 
> 2) Congestion control:
> 
> One system may have higher overheads than another which may cause
> different rate limitation to be required.
> 
> 3) Resource Control:
> 
> Processing resources may be consumed with a particular encoding
> (perhaps more than another).
> 
> This may encourage identification of the mobile in order to limit
> resource consumption on a per-node basis.
> 

UDP Request sent by MN and UDP Reply sent back by Server, or
RS and RA?

> What discovery mechanisms can we assume?

Discovering a server or a service is typically done whith DHCP.

> Is it necessary to have IS servers > 1 hop away?

If IS happens as RS/RA then IS server must be on same link as terminal.
 It it happens as ICMP or UDP then it can be several hops away.

I doubt that IS Server that is not on the same wireless link (same
wireless link) as the MN could instruct the MN about link
characteristics of that link, it would look so weird.

> What level of trust is required for IS servers?

I wonder about trust in general in 802.21.  Operator's oppinion
expressed here at some point was that an operator controls both a WiFi
net and a GPRS net and wants to handover a terminal between the two.  In
this typical case operator controls actually everything so trust issues
may be relatively simple.

> Is the communication datagram oriented or stream oriented?

If MN and Server are on same wireless link and Server needs to instruct
the MN about the wireless conditions then communication needs to be very
quick because link characteristics change so quickly, so I'd rather see
UDP than TCP.

> Looking too deeply into the content means that the big questions are
> likely to be obscured, compared to more fundamental ones, which will
> affect sequencing, congestion and resource control anyway...

I agree.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Oct 2005 13:09:51 -0700

What are the 802.21 requirements as answers to these questions?

I do have my own ideas about how to answer them, based on my experiences 
with other protocols of this sort, but I think we need to hear what 802.21 
wants first.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 17, 2005 8:37 PM
Subject: [Mipshop] Containers and not content for handover 
informationservices

---

From: Greg Daley <[email-masked]>
Date: Wed, 19 Oct 2005 09:11:18 +1000

Hi James,

I'm happy to wait for IEEE to come with a set of official
requirements.

I do also think we need to inform the discussion over here though,
so that MIPSHOP isn't left at a standing start, when it comes
to advising additional requirements, and specifying solutions.

That's why there's a (personal opinions) take of the use cases
of IS described in draft-faccin-mih-infoserv-01.  I'd like that
document to reflect more of the understanding of 802.21 and
MIPSHOP, once those ideas are available.

Greg

James Kempf wrote:
> with other protocols of this sort, but I think we need to hear what 
> 802.21 wants first.
> 
>            jak
> 
> 
> 
> 
> ----- Original Message ----- From: "Greg Daley" 
> <[email-masked]>
> To: <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Oct 2005 08:35:31 -0700

Greg,

I think as far as IETF is concerned, there is are already a few precedents 
w.r.t. link type information. Both FMIP and CARD have support for this. I 
think there are some lessons that can be learned from FMIP and CARD, about 
what works and not, and applied to a second generation link information 
protocol. We could summarize that in some form.

My concern is that if IETF comes up with something prior to the IEEE 
requirements showing up, there may be a significant difference between the 
two. In a certain sense, this is what has happened with FMIP and CARD, not 
specifically with IEEE but rather with respect to serious deployment 
prospects, and the lack of prospects for commercial deployment during the 
final stages of their development is one factor in their designation as 
experimental rather than standards track.

This doesn't mean that IETF can't continue to discuss, but it means that we 
need to be aware of this issue. I am firmly convinced that there is 
absolutely *no* point in going through the exercise of developing a second 
generation link IS unless there are vendors and operators out there lined up 
and ready to deploy. I think working with IEEE is more likely to cause that 
to happen, but there are no guarantees. One only needs to consider the fate 
of IAPP to see that sometimes IEEE protocols don't get widely deployed 
either.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 18, 2005 4:11 PM
Subject: Re: [Mipshop] Containers and not content for 
handoverinformationservices

---

From: Greg Daley <[email-masked]>
Date: Thu, 20 Oct 2005 09:15:19 +1000

Hi James,

James Kempf wrote:
> Greg,
> 
> I think as far as IETF is concerned, there is are already a few 
> precedents w.r.t. link type information. Both FMIP and CARD have support 
> for this. I think there are some lessons that can be learned from FMIP 
> and CARD, about what works and not, and applied to a second generation 
> link information protocol. We could summarize that in some form.

I think this could be really valuable.

> requirements showing up, there may be a significant difference between 
> the two. In a certain sense, this is what has happened with FMIP and 
> CARD, not specifically with IEEE but rather with respect to serious 
> deployment prospects, and the lack of prospects for commercial 
> deployment during the final stages of their development is one factor in 
> their designation as experimental rather than standards track.
> 
> This doesn't mean that IETF can't continue to discuss, but it means that 
> we need to be aware of this issue. I am firmly convinced that there is 
> absolutely *no* point in going through the exercise of developing a 
> second generation link IS unless there are vendors and operators out 
> there lined up and ready to deploy. I think working with IEEE is more 
> likely to cause that to happen, but there are no guarantees. One only 
> needs to consider the fate of IAPP to see that sometimes IEEE protocols 
> don't get widely deployed either.

Absolutely.  I don't think it's worth MIPSHOP's cycles if
there's no chance of deployment.

AFAICS you're right about working with IEEE on this one:
There are no guarantees.

When we get to the point where people will have to put a lot
of work in, the picture may be clearer though.

I'd like to keep the pot simmering, so that the group is ready
to take the chance when if it arrives.

I'm certainly not thinking of going straight towards development yet.

Greg