Re: Real time applications on LTNs or 2.5/3G networks

Hello Ruud,

I have one request for your study.  Please also investigate SCTP's use in wireless.  SCTP is 
defined in RFC2960 also see http://www.sctp.org/.  There is not much (if anything) published
on this currently, and if you are conducting some experiments, it would be very interesting to
compare SCTP with TCP in your experiments.

SCTP originated at Motorola and was subsequently heavily modified and improved in the 
IETF transport area.  In our lab work at Mot we found it to be quite useful for wireless links 
as well, although that aspect has not been widely publicized.  In particular, the multi-homing
feature can be used for path/route diversity in cellular and ad hoc networks.

Also, w/respect to TCP and wireless, there are several excellent papers that describe the
downfalls.  Randy Katz's work at U.C. Berkley is particularly interesting.

Best regards,

Phil Neumiller

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
Sent: Friday, July 12, 2002 8:15 AM
Subject: [pilc] Real time applications on LTNs or 2.5/3G networks


> Hello all,
> 
> I am considering starting a new paper on improving realtime TCP applications
> on LTN. However before I start duplicating work I would like to ask this
> group if such work is allready beeing done?
> 
> Before you respond, let me give some background:
> 
> I am testing several applications for performance on the GPRS network (2.5G)
> and am running into the following problem:
> 
> Realtime applications (mostly terminal applications/thin clients) that use
> TCP as protocol work pretty bad over GPRS. There are several reasons for
> this:
> 1) Because of Nagle ofter the congestion window is 1 packets and triggers no
> form of Fast Retransmit nor Limited transmit
> 2) When disabeling Nagle, the IP packet overhead in general is too high
> resulting in Queueing delay
> 3) Any other suggestions from this group?
> 
> For this problem some possible solutions exists e.g. using UDP and make your
> own protocol or adding timers that throthle data before sending it without
> Nagle.
> 
> I could write some Informational RFC discussing possible solutions for this.
> 
> Any ideas or comments?
> 
> Ruud Schramp
> 
> 
> 
> +31-70-3362341
> 
> KPN Valley
> Postbus 421
> 2260AK Leidschendam
> Netherlands
> 
> 
> _______________________________________________
> pilc mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pilc
> http://www.ietf.org/html.charters/pilc-charter.html
> http://pilc.grc.nasa.gov/


_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/