Subject: RE: [seamoby] Update on Issues from IETF meeting

From: "Hamid Syed" <[email-masked]>
Date: Tue, 14 Aug 2001 09:19:05 -0400

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Monday, August 13, 2001 7:19 PM
To: [email-masked]
Subject: [seamoby] Update on Issues from IETF meeting

All,

Although I need to put together the minutes from the London meeting last
week,
I'd like to send out the results from our Issues discussion, and request any
comments before we move on.

There are four pending issues:

Issue 2: This issue has to do with the adoption of the proposed requirement
4.3.

	The consensus in the meeting was to adopt the requirement 
	with some minor wordsmithing.

Issue 4: This issue had to do with new terminology for proactive and
reactive
Issue 7: Remove the terminology proactive and reactive

	After some intense discussion on the issue, it was decided to remove
	proactive and reactive, and instead adopt a very simple requirement
	similar to:

	"Context Transfer may occur prior to, during or after a handover."

	Nearly complete consensus on this approach.

[Hamid] I will not raise my hand for this one. I do not understand the
rationale why the proactive and reactive terms are being removed. There are
clear advantages of performing a context transfer prior to the traffic
re-direction. What we want to achieve with context transfer? Just dumping
some information from one AR to the other and we do not even care how it can
be used for seamless handover. 

Issue 5: This issue was a request to support multi-phasic CTs

	The text proposed at the meeting was:
	"4.9 Context information MAY be transferred in phases, allowing for 
	time critical state to be sent first, and non-time critical state 
	to be sent later.

[Hamid] I guess ct in phases is ok but how can the receiver of the context
process the time-critical information if it had not received the other part
of it.?. I guess the order is reverse. The non-time critical should be
transferred first.

	The cost of building and sending smaller packets is less, as well 
	as parsing and processing by the receiver. "

	The consensus at the meeting was to adopt the text, but a comment
was
	made that how one defines time critical is an issue since anything
	could be send in the initial CT message.

    Each CT profile would need to specify whether it is time-critical.

[Hamid] what is ct profile??? I do not know this term.

If someone has any comments on the above, I'd like to hear them now. As you
know, decisions aren't made at meetings, and the list is still the preferred
medium to provide comments. If I hear no objections by 8/21, these changes
will be included in the next revision of the draft will be send to WG last
call.

Thanks,

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 14 Aug 2001 07:12:43 -0700

> be used for seamless handover. 

But I think that we all agreed that pro/re were modes, and did not change
the protocol in any way. It really came down to implementation, and how
CT would be invoked by the mobility management subsystem. So, what the very
complex text was really trying to state was that Ct can occur at any time,
and since the text wasn't really specifying a requirement per se, the group
felt that the above wording was clearer (and I tend to agree).

> of it.?. I guess the order is reverse. The non-time critical should be

Right, well Gary sent out text earlier that I like even more

"4.9 Context transfer MAY occur in phases"

That was we get away from defining why, and ...

>     Each CT profile would need to specify whether it is time-critical.

... we don't have to worry about comments like these :)

Thanks,

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 14 Aug 2001 16:07:31 -0700

Hello Hamid,

Hamid Syed wrote:

> rationale why the proactive and reactive terms are being removed.
> There are clear advantages of performing a context transfer prior to
> the traffic re-direction.

Right. The new text allows for that isn't it ? You could do CT prior to,
during or after a handover.

> [Hamid] what is ct profile??? I do not know this term.

It could be something that identifies and defines the particular feature
context.

Regards,

-Rajeev

> will be included in the next revision of the draft will be send to WG
> last call.
>
> Thanks,

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Tue, 14 Aug 2001 19:26:07 -0400

RE: [seamoby] Update on Issues from IETF meetingTake a look at ROHC WG Profiles.  Each compression profile describes how to compress a protocol:

TCP compression Profile
UDP compression Profile . . . 

For CT we could have:

TCP context profile
UDP context profile . . .

- Kulwinder.

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 14 Aug 2001 16:46:19 -0700

Hello Kulwinder,

Kulwinder Atwal wrote:

> Take a look at ROHC WG Profiles.  Each compression profile describes
> how to compress a protocol: TCP compression Profile
>
>
> Rajeev: as far as I am aware, a TCP compression profile has not been
> defined yet.
>  UDP compression Profile . . . For CT we could have: TCP context
> profileUDP context profile . . .
> Rajeev: In general, it could be profiles for HC/QoS/... Indeed, we
> have made an attempt to define some of these for HC and QoS in our
> draft contributions to the group.
>
> Regards,
>
> -Rajeev
>
>
>
>
>
>
>
>
> - Kulwinder.
>

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Tue, 14 Aug 2001 20:07:07 -0400

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "Kulwinder Atwal" <[email-masked]>
Cc: "Hamid Syed" <[email-masked]>; "'Pat Calhoun'"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, August 14, 2001 7:46 PM
Subject: Re: [seamoby] Update on Issues from IETF meeting

> > Rajeev: as far as I am aware, a TCP compression profile has not been

No, but I hear it is being worked on.  I saw some presentations at
Minniapolis.

> > Rajeev: In general, it could be profiles for HC/QoS/...

I don't see how one could have single profile for HC when each HC Profile
has a different context.
For example, RTP has a sequence number, while UDP does not.

Unless the intent is to create "mini-profiles" on a protocol basis.  There
is no guarrantee that each MN will, at any one time, have all contexts
active.

How do you specify which HC profiles are active, or not per MN?

- Kulwinder.

Indeed, we

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 14 Aug 2001 18:17:00 -0700

> For example, RTP has a sequence number, while UDP does not.

Rajeev: I didn't imply that a single profile would suffice for HC (or QoS).
You certainly need more than one. Would you be willing to review
draft-koodli-seamoby-hc-relocate-01.txt ? :-)
You will find discussion on this as well as a CT profile for IP/UDP/RTP HC.

Regards,

-Rajeev