Re: [Seamoby] AD Review Issues with draft-ietf-seamoby-ctp-08.txt

["James Kempf" <[e-mail]>]

Rajeev,

Since nobody has responded to your message, I suppose I must. Note that I'm
responding here from a technical standpoint and not as WG chair.

Your assertion that we do not know today definitively how these access
networks will be deployed, nor do we really have any data on existing
deployed hotspot or WAN wireless networks sounds accurate, at least as far
as I'm aware. My assertion in the original email about congestion was based
on talking with people who have been working on congestion control for most
of their career and my limited knowledge about how some of these networks
are deployed. In the US, it is common to underprovision DSL networks by up
to 80:1 through a T1 line, and T1 is also being used extensively for hotspot
deployments, such as T-mobile's deployments in Starbucks. Nevertheless,
there are other networks, such as most of those in Japan, that don't use T1
much, and intuition is never a substitute for hard experimental data. Until
someone has measured traffic on access networks and can say whether
congestion will be a problem, it remains conjecture.

With regard to your proposal to use ICMP, even disregarding the congestion
issue, I think this is a basic nonstarter as far as CTP is concerned, since,
at least for IPv6, there is a limitation on packet size of the MTU, and I
think there is also a limit for IPv4,  but I've been unable to find a
reference. While again it is difficult to predict, it is possible that the
amount of context information could exceed that limit, since unlike FMIP,
the amount of information in a CTD message is not fixed. A node could have
any number of video/audio sessions active, to say nothing of other context
information.

From the standpoint of achieving a uniform interrouter protocol for mobile
handover information transfer, it would certainly be prefereable from an
architectural standpoint to have one transport protocol for all of FMIP,
CARD, and CTP. Currently, FMIP uses ICMP, CARD uses a UDP with fixed
retransmit (also a problem that will need to be fixed), and CTP used UDP
with optional, unspecified fixed retransmit interval. Since FMIP and CTP are
time critical, their requirements for timeliness are a bit different than
for CARD, but I think that the congestion properties of the networks in
which they operate would be expected to be approximately the same. Do you
agree?

The proposal for SCTP was based on what I believe is called "partial
retransmit" mode, in which SCTP only retransmits until a timer pops. This is
different from TCP. I'm not familiar with the details of this, maybe someone
who knows SCTP better can comment. The people who I've talked to about this
believe that the partial retransmit mode should accommodate the need for
timeliness. With regard to the assertion that reliability is not needed
because the node can re-establish the state anyway, this is true, but the
difficulty is that if access networks do turn out to be congested and the
traffic is dropped, the handover optimizations could potentially fail so
often as to make them not useful, which is the point I was trying to make in
the original note.

Putting back my WG chair hat on, Allison's proposal to use SCTP is based on
the tradition in IESG/IETF of conservative design when it comes to questions
of congestion control, i.e., it is better to put something in there now that
has congestion control features than find out later, to our regret, that the
protocols are causing a congestion problem, even though they are
experimental and even though they are published with an applicability
statement warning people about the potential for a problem. This tradition
has served IETF well in the past, and I believe it makes a lot of sense now.
If it does turn out after much measurement and experimentation that
congestion is not a problem in wireless access networks, the transport
protocol can be changed when and if CTP ever goes to PS.

As a practical matter, we really do need to get this spec published, and we
cannot get it published (indeed it will not even be reviewed by the IESG)
until we satisfy Allison's concern about the transport protocol. Therefore,
I'd like to again propose that we use SCTP. I think we should also include a
paragraph in Section 3 which summarizes our discussion on this list, and
explicitly calls out the transport protocol as an area where more research
is needed, which I hope will satisfy your concerns about our current state
of knowlege in this area.

            jak



----- Original Message ----- 
From: "Rajeev Koodli" <[e-mail]>
To: "James Kempf" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 19, 2004 3:25 PM
Subject: Re: [Seamoby] AD Review Issues with draft-ietf-seamoby-ctp-08.txt


>
> Hello Jim,
>
> "Since access networks of these
> types are just where one might expect congestion to develop, the frequency
> of packet drops for UDP without retransmit would be expected to be high
> enough to render the protocol unusable in general. " does not sound like a
> good reason for an experimental protocol. We have not had any
> experiences with actual deployments to support this seemingly logical
> statement. And, one could argue that we could state in the applicability
> statement that "the usefulness of the protocol on routinely congested
> networks could be limited". BTW, I am not arguing for UDP. I would
> like to have the CTP messages as blocks that could be carried in ICMP
> so that they could be used in conjunction with fast handovers.
>
> As you note below, both TCP and SCTP have shortcomings not suitable
> for CT which is useful mostly when synchronized tightly with fast
> handovers. The distinction between failed CT due to a dropped packet and
> a CT that is not on time is thin. Besides, features (QoS, HC) always need
to
> have recovery mechanisms anyway, which would re-build the state.
> So, I would suggest using ICMP without re-transmissions. We know
> the links where it works. We would like to try it on bottlenecked links
and
> provide some data, which we could use when the spec is up for PS.
>
> Regards,
>
> -Rajeev
>
>
> >
> > Issue 2
> > --------
> >
> > Issue: The draft as written specifies using UDP without retransmit for
the
> > transport protocol. This is not acceptable from a congestion control and
> > usability standpoint, the points made in Appendix  A about timing
> > notwidthstanding. Both Allison and James brought up these issues at
various
> > times during the requirements discussion and during previous reviews of
the
> > draft.
> >
> > The issue with UDP is that CTP is expected to be used frequently between
> > access routers in a wide area network, like between two hotspot clusters
> > connected by T1 or other low capacity lines. Since access networks of
these
> > types are just where one might expect congestion to develop, the
frequency
> > of packet drops for UDP without retransmit would be expected to be high
> > enough to render the protocol unusable in general. While the Working
Group
> > could develop a specialized UDP retransmit algorithm, there is no need
since
> > both TCP and SCTP could provide adequate performance for CTP. Below are
two
> > suggestions for resolution of the issue, and a preferred resolution.
> >
> > Suggestion 1: Use TCP.
> >
> > The advantage of this suggestion is that TCP is already widely
implemented
> > and is well understood, so it could serve for immediate implementation
and
> > experiment. The disadvantage is that TCP provides no way to control the
> > retransmit timer in general, so the timeliness of the transfer could not
be
> > assured without additional measures.
> >
> > Suggestion 2: Use SCTP.
> >
> > The advantage of using SCTP is that it provides a partial reliability
mode
> > which allows the retransmit timer to be set. This would allow the
timeliness
> > of the transfer to be controlled. The disadvantage is that SCTP is not
yet
> > widely implemented.
> >
> > Preferred Resolution: Suggestion 2.
> >
> > _______________________________________________
> > Seamoby mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/seamoby
>


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