[e2e] Is a non-TCP solution dead?

[Lynne Jolitz]

> There is so much *myth* about how "bad" TCP performs over wireless, and I 
> get so tired of reviewing papers that start with "... wireless links are 
> characterized by high packet loss rates caused by transmission 
> errors ...".

How do you explain the results of the January 2003 Keynote study? 
http://www.keynote.com/downloads/case_studies/keynote_wireless_study.pdf
Keynote's business purpose is to measure availability and loss for their customers - if they don't do this well there's no value in their service.

They say that text messaging as an example they can measure is not great - it's as bad as 87% for one provider, not counting the unacknowledged nature of text messaging which suggests to them that fewer than one in 20 after this 87% is accounted for actually makes it through.

They're either mistaken and don't know their business, or there is a problem here that is being detected. I'm not a Keynote employee or investor, so I'd like to know which is which here.

> Having worked on this subject for a couple of years, we have learned that 
> TCP  performs *great* most of the times (yes, rare corner cases 
> exist) *if* 
> the wireless subnetwork is designed right. On this subject, I can only 
> recommend to read draft-ietf-pilc-link-design-13.txt which is a 
> soon-to-be-BCP-RFC. RFC3366 provides additional detail on the subject.

As to TCP being overdone, the problem isn't the argument about whether flow control signals congestion or dropout as much as the incredible span TCP handles and transverses. Because of the peculiar definition of end-to-end implied, TCP has to span an enormous range of latency and hops, which it does admirably well with amazingly little in terms of process and information, so Reiner is right here. 

But if one believes the Keynote studies and other people on this list and just wanted to solve the problems discussed in a simple way, one could break the problem down into smaller segments (spans) for TCP - divide and conquer reduce complexity greatly. In this case, we'd spend our time discussing the details as to how best to accomplish this while preserving the semantics. But now were back debating the definition of end-to-end again.

Perhaps some intellectual flexibility and creativity here would preserve the semantics and provide some way out of these dilemmas. Of course, if everyone gets hung up on definitions, the vendors will just sell ad hoc solutions. Remember how NAT came about...

Regards,
Lynne.