Subject: Preferences and Requirements Options (was Re: [Seamoby] Proposal to resolve remaining CARD issues)

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Oct 2003 19:57:05 -0700

hi Marco,

Marco Liebsch wrote:

>
> Issue#17: Preferences/Requirements sub-option - One
> of them is sufficient?
> ---------------------------------------------------
> Proposal is to keep both, since this implies just the definition of a 
> further sub-option type, which indicates
> that only Attributes without any Data field will follow
> in case of receiving a Preferences sub-option.
> The Requirements parameter sub-option will carry then a
> list of Attribute-Value pairs, the Preferences parameter
> carries a list of Attributes (just the AVP Code and
> Length, no Lifetime, no Data).

one has to still implement both, right?

I still think one of them is enough. I suggest removing the Requirements 
Sub-Option.
it causes more harm than benefit. here is one example.

lets assume none of the CARs were able to meet the MN's requirements. 
the CARD
Reply returns empty. because of the MN's strict requirements, it loses 
connectivity.
isnt that worse than picking a CAR with less capabilities? a local 
decision at the
MN is better than the MN not getting any CARs.

Vijay

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 10 Oct 2003 09:51:39 -0400

> MN is better than the MN not getting any CARs.

Vijay,

The MN does not lose connectivity necessarily in the case you described.
It depends on the timing of the CARD Request/Reply in the handoff process.
If the requirements are something the MN can have flexibility on such as
bandwidth, the MN should send the query much earlier before the MN's old
link gets too weak.

However, if the requirements are something in which there is no flexibility
with the MN such as link type, the empty reply means there is no access
network supporting the link type. In the case, losing connectivity may not
be unavoidable if the MN keeps moving far from the old access point/base
station.

Filtering out CARs based on supported link types is an obvious example
showing the benefit of the Requirements sub-option.

Regards,

Eunsoo

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 10 Oct 2003 11:20:19 -0700

> The MN does not lose connectivity necessarily in the case you described.

what I meant, if there are no candidate ARs, the MN loses connectivity
eventually.

> be unavoidable if the MN keeps moving far from the old access point/base

let the MN make the decision, if no CARs can satisfy its requirements.
and you have the preferences options for the MN to tell the current AR
what it wants.

Vijay

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 10 Oct 2003 16:13:20 -0400

> what I meant, if there are no candidate ARs, the MN loses connectivity

If there is no candidate ARs supporting any link type available for the MN,
certainly the MN will lose connectivity. It is the case regardless of CARD
Request/Reply or the Requirements sub-option.
If the Requirements sub-option is used by the MN, the MN should consider
what it will do in the case the Reply is empty.

> and you have the preferences options for the MN to tell the current AR

Sending a Requirements sub-option is upto the MN, that is, the MN's
decision. It is not the current AR that decides the target AR even if the
Requirements sub-option is used. Certainly the Requirements should be
explicit and clear.
The need of Requirements sub-option arises because there could be many CARs
in the area. In the case, the CARD Reply may contain much information that
is not useful for the MN at all. It is waste of bandwidth and resources of
the MN.
The Preferences sub-option is used to specify what attributes of CARs should
be included in the CARD Reply while the Requirements sub-option is used to
specify what CARs should be included in the CARD Reply. So the two
sub-options have different roles.
Please let me stress that sending a Requirements sub-option is OPTIONAL to
the MN. The MN does not even have to support it if the developer decides so.

Eunsoo

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Oct 2003 17:54:28 +0200

Vijay Devarapalli wrote:

> I still think one of them is enough. I suggest removing the 
> Requirements Sub-Option.
I don't want to provide input for a huge discussion here, but I don't see
any reason why not to have 2 separate sub-options for 2 separate
functions. If these should be merged, ARs need to check always whether
or not AVPs carry a Data field, if not then this is interpreted as a 
"preference",
otherwise as a "requirement" parameters.....

However, from implementation point of view, the current one is the simplest
case, since the format for both are the same, just use a separate type 
number
for these sub-options, that's it. This makes the meaning of the parameters
already clear when processing the header of the sub-option, right?

marco

---

From: "James Kempf" <[email-masked]>
Date: Mon, 13 Oct 2003 10:50:14 -0700

Marco/Eunsoo,

Can you explain what the exact semantic difference is between these two
options? If it isn't large, then I'd suggest merging them, based on the
premise that "simpler is better"?

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; "Seamoby"
<[email-masked]>
Sent: Friday, October 10, 2003 11:20 AM
Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
Proposal to resolve remaining CARD issues)

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 13 Oct 2003 14:10:55 -0400

The Requirements sub-option is used to filter out the CARs to be included in
the Reply.
For example, it can say " CARs supporting 802.11b interface". Then the
current AR puts CAR information satisfying the conditions (requirements). It
is useful since any CAR that does not support the link types available for
the MN should not be included in the Reply. Since the current AR does not
know what link types are available for each MN, it is the MN that should
tell the current AR about them.

The Preferences sub-option is used to filter out the attributes to be
included in the Reply.
For example, it can say "link types, supported IP versions, authentication
protocols". Then the current AR puts those attributes among all the
capability (attributes) of the CARs. That is, the Reply does not contain
"cost = free" of the CARs but it can contain information such as "link type
= 802.11b, 802.11g" "supported IP versions = ver4, ver6", "authenticated
protocols = RADIUS" for each CAR entry.

So the two sub-options are for independent filtering of the CAR information.
One cannot replace the other.

Also, merging the two sub-options does NOT make anything simpler. Rather, it
makes the sub-option more complex to decode.

Eunsoo

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Eunsoo Shim"
<[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; "Seamoby"
<[email-masked]>
Sent: Monday, October 13, 2003 1:50 PM
Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
Proposal to resolve remaining CARD issues)

---

From: "James Kempf" <[email-masked]>
Date: Mon, 13 Oct 2003 12:42:48 -0700

So why not merge them into a "filter" suboption? And have the filter
language reflect the two different uses?

            jak

----- Original Message ----- 
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Vijay Devarapalli"
<[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; "Seamoby"
<[email-masked]>
Sent: Monday, October 13, 2003 11:10 AM
Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
Proposal to resolve remaining CARD issues)

> > > > network supporting the link type. In the case, losing connectivity
may
> > not

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 13 Oct 2003 15:52:45 -0400

The two sub-options have different formats as well as different semantics.
Two separately defined sub-options are simpler in usage and
encoding/decoding, I think.

Eunsoo

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; "Vijay Devarapalli"
<[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; "Seamoby"
<[email-masked]>
Sent: Monday, October 13, 2003 3:42 PM
Subject: Re: Preferences and Requirements Options (was Re: [Seamoby]
Proposal to resolve remaining CARD issues)

> > The Requirements sub-option is used to filter out the CARs to be
included
> in
> > current AR puts CAR information satisfying the conditions
(requirements).
> It
> > Also, merging the two sub-options does NOT make anything simpler.
Rather,
> it

---

From: "James Kempf" <[email-masked]>
Date: Mon, 13 Oct 2003 12:54:00 -0700

Eunsoo,

I do not have a lot of time to discuss this, so this will be my last email
on the topic.

> encoding/decoding, I think.

Can you explain how having two sets of parsing code is simpler than having
one?

        jak

> > > > > and you have the preferences options for the MN to tell the
current
> AR

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 13 Oct 2003 16:25:42 -0400

> Can you explain how having two sets of parsing code is simpler than having

The Requirements sub-option should contain a list of AVP while the
Preferences sub-option should contain only a list of attribute IDs. That is,
they have different formats. By knowing the type of sub-option from the
sub-option header, the receiver knows what format to be expected.

Also by putting all the Requirements separately from the Preferences, the
receiver can get the Requirements at once without having to figure out
whether each filter is for Requirements or Preferences.

An alternative suggested in the mailing list to merge the two sub-options
was putting a empty value for the AVP to indicate the AVP was for
Preferences. To do this, each AVP for Preferences should have the length
field as well which indicates always zero. It is waste of bandwidth. Reading
the length field is waste of the receiver resources (time and power). In the
end, the receiver should logically separate Requirements from Preferences
from the merged filter. So from the viewpoint of implementers, merging the
two sub-options into a single sub-option requires another step to separte
them in the receiver side.

Logically the two filters are separte to the sender as well as the receiver.
Having them separated physically is clearer for both of the sender and the
receiver.

Eunsoo

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 22 Oct 2003 18:48:56 +0200

Eunsoo Shim wrote:

>>>The two sub-options have different formats as well as different
>>>      
>>>
>semantics.
>  
>

I agree with Eunsoo here, that also the logical function should be taken 
into consideration. How to
process payload of the sub-option is clear already after processing the 
sub-option type, whereas
when using one sub-option for both functions, individual AVPs need to be 
checked. In the latter
case, the length should not be 0x00 but 0x03 in case of just 
transmitting Attributes...
Furthermore, should we allow then also a "mixed" approach, where this 
merged sub-option
can convey Attribute-Value-Pairs for CAR filtering together with only 
Attributes for
capbility filtering...? I think then ist really starts to get complex 
without getting any benefit.

I propose to keep going for the 2 separate sub-options. However, in case 
we drop also the
AVP Length fields in a Preferences sub-option for bandwidth 
optimization, we have the
same problem as we have for the L2-ID, which is related to "length 
without padding" and
"length with padding". For a solution I propose the following: Just list 
Attribute values (each
has 16 bit). In case (# of attributes) mod 2 = 0, fine, otherwise attach 
Attribute value
0x00 for padding. Value = 0x00 should then not be used for capabilities.

What do you think?

marco

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 22 Oct 2003 12:56:16 -0400

> 0x00 for padding. Value = 0x00 should then not be used for capabilities.

I agree to the proposal in the above.

Eunsoo

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 23 Oct 2003 11:38:00 +0200

If there are no concerns to the proposed solution until Friday, we'll 
close this issue then
and adjust the text in the draft for the next update.

Any comments?

marco