[e2e] Is a non-TCP solution dead?

[Cannara]

Ok, got it Spencer.  Apparently there are flows that mock TCP, so any tools
that look only at Protocol and Port fields will fail to expose them.  I
haven't seen these myself, but I believe others on this list have.  

In any case, I don't really care that TCP is in the majority or not.  If it
is, then the situation is worse, because then more flows will be subject to
unreasonable slowdowns, which is what I see at client sites -- e.g., last
week's 1% loss => 50% slowdown example.  If TCP is not in the majority, then
many non-TCP folks are getting good flows and the TCP ones are just getting
dinged more.

The bottom line is that the research on managing the network layer has been
put off for 20 years or so and is long overdue.  TCP diddling won't do the job
needed, because TCP is faced with strict undecidability.  There have been
links from IP to TCP proposed to help, but unless even IP has better path
info, the game is not going to be played well.

Alex

Spencer Dawkins wrote:
> 
> 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
> >
> >