Subject: Re: [MOBILE-IP] RP Flow Control

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 23 Mar 2000 16:23:44 -0000

> you can always put a buffer in the RNN, since the wireless physical
> link is really terminated there (in fact there is such a buffer
> already in the RNN for RLP).
>
In fact 3GPP does exactly so (buffers in the RNC and no flow control between
the RNC and the SGSN).

alessio

PS Sorry to pollute the MIP list with this kind of discussion,
   but this is necessary in this case.

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 23 Mar 2000 19:08:07 -0000

> I do not believe that any congestion can be taken care by providng
> buffering.
> Buffering delays the congestion does not fix it , unless end to end
> feedback
> mechanism is povided.  Comments ?
>
>
I comment that your mechanism just moves the congestion to the PDSN, If I
understand your proposal. How do you solve the problem
of congestion in the PDSN, missing an end to end feedback?

The best I can see one can do, in IP networks, is to actively manage buffers
(RED, LQD+WFQ and drop from front ...). There's ECN to be used
experimentally, but that is anyway ultimately relying on some active queue
management augmented with ECN capability.

there's a dangerous slip into transport issue here... are we supposed to do
that here?

alessio

---

From: Ajoy Singh <[email-masked]>
Date: Thu, 23 Mar 2000 13:14:18 -0600

> of congestion in the PDSN, missing an end to end feedback?

Yes this just moves congestion to PDSN.  But just look at the following points.

1. PDSN can drop packets before doing compression.

2. The dropping of one LZW compressed frame at RNN can cause mobile station to
drop all compressed packets of the compression window. So dropping packet at RNN
means, we have to send some frames over air interface which will be dropped
eventually at mobile station.  This is not desirable as we are wasting RF
resources for nothing.

3. Moreover R-P interface tunnels octet stream so RNN might be not able to make
efficient dropping mechanism, unless we say that  GRE packet  encapsulates
complete PPP frame. I do not remember reading any such thing in RP document.
Correct me in case i missed it. RNN might end up dropping some thing which just
contain PPP  frame boundary.  In this case incomplete PPP frame will cause CRC
errors at mobile station.  We do not want to send something over SCH, which we
know is going to be erased by mobile station. Note in case of L2TP framing is
done at LAC, so such problem does not exist.

regards,
ajoy

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 23 Mar 2000 20:48:46 -0000

Ajoy,

these considerations are very interesting.

> 1. PDSN can drop packets before doing compression.
This is a laudable goal. Have you an estimate of
the impact of saving compression in (transient) congestion condition?
I assume that there are some compression processing resources that are
reserved, not to starve flows in case there happens to be
no congestion, right?
This appears not to be a big plus on its own right.

> eventually at mobile station.  This is not desirable as we are wasting RF
This is a laudable goal. But I start to question the merits of the choice
that lead to have a PDSN handling the link layer and compression if the one
you describe is a significant problem due to that choice. The 3GPP
architecture is superior from this respect. And also some proposals that are
aiming at not having link layer terminated at the PDSN should be seriously
considered, I would guess.
Anyway, I'm not going to stir the pot further on this, since
I was (and I am) not involved in the dicussion on R-P and I may be missing
something.

> done at LAC, so such problem does not exist.
This is not a so laudable thing. I hope you are not going to
send incomplete PPP frames encapsulated in any protocol used over the R-P
(the system would start to suck quite a lot).

alessio

---

From: Ajoy Singh <[email-masked]>
Date: Thu, 23 Mar 2000 17:37:44 -0600

Hello Alessio,
Thanks for your comment buit still i do not understand some of  your comments.
Can you explain this in more detail ?
regards,
ajoy

> This appears not to be a big plus on its own right.

I do not have any exact figure about this right now.   Can you explain this
problem in more detail as i do not see any thing here which is a problem ?

> I was (and I am) not involved in the dicussion on R-P and I may be missing

Well i do not think this is a architectural issue in 3GPPP2. I believe it is
perfectly all right to terminate PPP at PDSN and RF at RNN. This makes more
business sense as PDSN is something which is implemented by data communication
companies and RNN is something which is implemented by Cellular Vendors.  So why
should we mix them up. Moreover, if you terminating PPP at PDSN it will be mess
to implement PPP compression mechanism at RNN.  I would guess we will be better
off not suggestion any such thing. Comments ?

> (the system would start to suck quite a lot)

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Fri, 24 Mar 2000 09:51:11 -0000

> > > Yes this just moves congestion to PDSN.  But just look at the
> following
> > > points.
> > >
I have a problem in understanding your question. I believe
I'm not raising any problem, I'm just saying your point 1 doesn't
seem to be a compelling reason/advantage.

> > > drop all compressed packets of the compression window. So dropping
> packet
> > > at RNN
> companies and RNN is something which is implemented by Cellular Vendors.
>
Well, In standard bodies people define open interfaces.
Generally, no implication is involved by this on who builds
what.

I'm not questioning the need for an open interface, I'm questioning whether
the problems you are trying to solve
could have been avoided with better definition of such an open interface.

If the compression problem you mention affects consitently RF
resource consumption in RNN congestion condition, and this
is expected to happen frequently, then I would state you
are trying to patch a badly designed system. This as far as good
engineering goes.

alessio

---

From: Rohit Verma <[email-masked]>
Date: Fri, 24 Mar 2000 08:43:20 -0600

I guess the question is not of starving flows, the point is that the
     links on either side of the RNN (Radio and PDSN) are not balanced.
     Therefore there is a situation where RNN will be unable to keep pace
     with forwarding packets from the PDSN to the Radio.
     So somewhere packets will have to be buffered or dropped. From a
     performance standpoint it will be advantageous to drop packets before
     any history specific information is added to them. This history
     specific information could be compression/encryption etc...
     The implementation of the mechanism is optional so it should be
     completely unobtrusive to systems that do not implement it.
     As packets are paced, upper layer protocols will eventually take over
     and adjust their window sizes so that there is end-to-end control.
     The proposed solution is not to replace exiting mechanisms but merely
     is a way to avoid performance degradation.

     Hope this helps
     Regards
     Rohit Verma

______________________________ Reply Separator _________________________________
Subject: Re: [MOBILE-IP] RP Flow Control
Author:  [email-masked] at Internet-USA
Date:    3/24/00 3:56 AM

alessio

---

From: Yingchun Xu <[email-masked]>
Date: Fri, 24 Mar 2000 10:25:28 -0600

Ajoy,
RP registration and GRE frame head have a protocol ID let you specifying what
will be tunneled. If you put PPP protocol ID 0x880B,
you will be able to encapsulate the whole PPP frame.

--Yingchun.

Ajoy Singh <[email-masked]> on 03/23/2000 01:14:18 PM

Please respond to Ajoy Singh <[email-masked]>

Sent by:  Ajoy Singh <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] RP Flow Control

regards,
ajoy

---

From: Ajoy Singh <[email-masked]>
Date: Fri, 24 Mar 2000 10:03:00 -0600

Thanks for clarifying this point. I thought this should be done this way. BTW still
we still have issue in case of compression which is the motivation factor of the
current draft.
regards,
ajoy