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

[Rajeev Koodli <[e-mail]>]

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