[e2e] Is a non-TCP solution dead?

[Spencer Dawkins]

Dear Alex,

Sorry, I was too cute to be clear. Let me try again.

Does anyone on this list have a trace of IP packets, marked as
TCP, that does not 

(1) make a reasonable attempt to perform slow-start/congestion
avoidance at the beginning of a connection, and 

(2) make a reasonable attempt to respond to packet loss by
reducing a congestion window?

I have seen recent (within six months) packet traces for a
commercial TCP that performs slow start and congestion
avoidance, blows fast retransmit, and then performs RTO-to-slow
start, but that's not the kind of thing I'm talking about.

I'm talking about unresponsive streaming media traffic that
carries TCP protocol numbers.

If the answer is "yes", I'm all ears. If the answer is "no" - I
don't see your point. 

If a streaming-media sender puts streaming media on a TCP
connection to vault firewalls, it stops acting like streaming
media. Maybe this is evidence that people would use more
streaming media without TCP (and usually HTTP) tunneling if
there were no firewalls dropping UDP/RTP traffic, but it's not
evidence that "the amount of non-TCP traffic is increasing", in
any way that affects network stability.

And I don't understand why you think measurement tools are being
"fooled" if they identify traffic that's marked as TCP and acts
like TCP as TCP.

Hope this is more clear and less cute.

Spencer

--- Cannara <cannara at attglobal.net> wrote:
> Now Spencer, you know the answer -- neither 1) or 2).  :]
> 
> The key in making any deductions is to know what the
> measurement tools do and
> how they might be fooled.
> 
> Alex
> 
> Spencer Dawkins wrote:
> > 
> > OK, I'll byte (ha!).
> > 
> > And the difference to the network between
> > 
> > (1) a TCP flow and
> > 
> > (2) a non-TCP flow tunneled over TCP
> > 
> > is?
> > 
> > (signed) curious
> > 
> > Or are we saying "a non-TCP flow tagged as TCP to get
> through
> > firewalls, but not conforming to TCP congestion avoidance"?
> I'd
> > be thrilled to see that...
> > 
> > It's interesting to look at the contents of tunneled packets
> for
> > traffic analysis, but if you tunnel over TCP/HTTP to get
> through
> > firewalls, the network thinks (correctly!) it's carrying
> > TCP/HTTP, end of sentence.
> > 
> > I would be interested in seeing references for "traffic that
> > masquarades as TCP, and probably as HTTP as well (how else
> would
> > you get through proxies?), but doesn't behave like TCP"...
> > 
> > --- Cannara <cannara at attglobal.net> wrote:
> > > John, I don't know enough about Inet2 to argue, but what
> you
> > > say makes sense
> > > from what my friends at Stanford, who manage parts of the
> SU
> > > net, have to
> > > say.  I believe, as the other emails have pointed out,
> that
> > > unless one
> > > actually looks at pkt contents, one can't really get good
> > > stats, due to the
> > > mimicking of TCP to get through filters.  This is likely
> why
> > > tools used by
> > > CAIDA, Sprint, etc. would have to be examined to see what
> > > they're actually
> > > looking at, if anything, other than simple port #s.
> > >
> > > Alex
> 
>