Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 15:16:59 -0500

Rex

I agree with all you have written, and yet I wonder if the problem
we are having getting VoIP and TCP to co-exist nicely is going to
be solved if we try to also solve the other problems you raise.
It would be nice, I think, to do so, but is it practical?

It does seem that we could tinker with TCP to allow it to be
less greedy than it is now, just as we can tinker with UDP to add
enough congestion control to prevent congestion collapse and to
appropriately trigger better TCP behavior.  Some of the proposals on
the DCCP list are, uh, interesting.  Like the one that suggests
that we use up to twice the bandwidth we need so that TCP will back
off enough to maintain what we need.  That would actually work, but
it may not be the best way to solve the problem.

On this list, the issue is do we actually have some requirements
in IEPREP that impinge on TCP that are similar to, but not exactly
the same as, the VoIP (or other real-time media) problem?  
Should we codify such requirements so that IEPREP could be added to 
the (small) chorus of voices that are talking about heresy -- making 
TCP not so greedy when no one else is pigging out.

I treat TCP replacements as "run away, run away fast" for much of the
reasons you have elucidated.  However, we have tinkered with TCP in
several ways of late.  Not all have (yet) been widely implemented,
but there is some hope.  The problem at the moment is that the UDP
toting media stream folks don't have any incentive to add congestion
control when the big bad TCP gobbles up all their bandwidth if they 
do or they don't, and the TCP crowd thinks if everyone else was just
TCP friendly (they even have an acronym!) life would be great, for TCP.

Brian

> -----Original Message-----
> From: Rex Buddenberg [mailto:[email-masked]]
> Sent: Monday, December 01, 2003 2:45 PM
> To: Rosen, Brian
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> 
> 
> Brian,
> 
> There have been a lot of wannabe TCP replacements over the years.  The
> CS landscape is littered with them.  Why didn't any catch on?
> 
> Well, a few did.  The transport layer functionality ended up 
> inside the
> application.  NFS is a good example of this.  But leaving that aside,
> why has TCP endured so well?
> 
> I suppose part of the reason is that Vint Cerf et al did so well.
> 
> But I think that one of the reasons that none of the wannabes never
> caught on is that they only have tackled one of the problems 
> and I think
> there are four:
> 	- reliable multicast.  More on this below.
> 	- built-in security.  Authentication of SYNs, for example.
> 	- QoS sensitivity (more than just congestion)
> 	- early open.  
> 
> Reliable multicast is a conceptually sticky problem and there is more
> than one correct answer.  I can articulate at least two:
> 	- in a reliable  file transfer type of operation, you 
> handle a late
> joiner by scrolling back to the beginning of the operation 
> because that
> late joiner needs the entire file.  This resembles TCP's reliability
> definition, but in a multicast environment.
> 	- in a common operational picture type of operation, 
> the session may
> have been in existence for an indefinitely long period of 
> time.  A late
> joiner may need a little history, but certainly not all of 
> it.  But once
> he's joined, he needs transport layer reliability of some sort.
> 	The problem is complicated by the fact that the only 
> scalable reliable
> transport systems are subscriber-oriented; originator-origin 
> systems all
> fail on ACK-implosion.
> 
> Early open means including real data with the opening SYN and ACK
> packets in the three-way handshake.  In TCP, these are overhead-only
> packets.  If you have a low-interactivity hop somewhere in 
> your network
> (e.g. a satellite throw), then the propagation time for this
> interactivity adds up quickly ... right at the front of a session.  
> 	XTP is one transport protocol that allows early-open 
> piggy backing; I'd
> assume there are more.  If you see somebody flogging a Performance
> Enhancement Proxy gadget, this is usually what's under the hood.  
> 
> QoS sensitivity.  The problem is sticky because there are several
> variables and attitudes ... you can't take the bellhead approach of
> simply counting Erlangs any more.
> 	- a lost packet, esp in a radio network, may not be a sign of
> congestion.  So the TCP reactions to a lost packet are now wide of the
> target.
> 	- 'fairness' needs definition.  TCP window, backoff, 
> and slowstart
> behavior are all socialistic -- all pigs are equal.  One of the points
> here is that we need to be able to make some pigs more equal than
> others.  CBR is a poor descriptor, IMHO, because it has to do with
> determinism, not congestion -- poor fit in nethead thinking.  If you
> want determinism, say so.  Bounded delay delivery is a synonym.  But
> determinism is _not_ what we need to make voice work and it's bought
> quite expensively in terms of bandwidth abuse.
> 	- there's no free lunch and there seem to be several 
> ways to spawn
> lose-lose situations.  Bandwidth efficiency, latency, jitter,
> interactivity and determinism are all in tension -- if you optimize
> latency/interactivity, you will pay for it in losses in bandwidth
> efficiency.  The default behavior at the network layer is to optimize
> bandwidth efficiency and take whatever hits are required in the other
> categories.  
> 	One of the current research projects at MIT is called XCP and is
> designed to smarten up the qos impairment problem.  It requires
> modifying the network layer protocols so that more information than
> simply a lost packet is passed to the transport layer.  There are some
> clever insights here, but I'm guessing XCP will be doomed to be a toy
> unless it accounts for the other three bullets on the next-gen list.  
> 
> 
> 
> On Mon, 2003-12-01 at 11:06, Rosen, Brian wrote:
> > This discussion relates to another thread happening on dccp.
> > The basis of that thread is a discussion of whether it is possible
> > to design a protocol that can be used for real time data that is
> > "fair" with respect to TCP.  One of the opinions on this thread
> > (mine among others) is that fairness can only be achieved if TCP 
> > also changes to be aware of "constant bit rate"-like streams.  
> > If there was a mechanism introduced into TCP that worked to allow 
> > real time media and TCP to better co-exist, as well as protocols 
> > that allowed media streams to better co-exist with TCP, 
> then perhaps 
> > there would be opportunities to address some of the 
> concerns Rex raises.
> > 
> > Please also let me comment on:
> > > 	- cut back a VTC to voice only.  The psychologists tell 
> > > us that a
> > > talking-head VTC has visual cues that we use for about 
> 5-10 minutes;
> > > after that we might as well turn the video off and just leave the
> > > audio.  
> > I'd like to see the citation on this research.  Our 
> research shows that
> > people in the same room with one another look intently on 
> the faces of
> > those talking, typically 90% of the time if engaged.  On a 
> well designed
> > "VTC", you can observe the same effect, even an hour or 
> more into a call.  
> > On a poorer quality system, participants tend to look 
> around the room a 
> > lot.  I wonder if the research you refer to is out of date.
> > 
> > And yes Scott, a router can't be expected to tell the 
> difference between
> > a well designed and a poorly designed video system. 
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Rex Buddenberg [mailto:[email-masked]]
> > > Sent: Wednesday, November 26, 2003 4:47 PM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low 
> priority calls
> > > 
> > > 
> > > On Wed, 2003-11-26 at 12:17, [email-masked] wrote:
> > > ...
> > > > 
> > > > The current GSCR was written for circuit mode. Unless we get it
> > > > changed, it will apply to packet mode (even when it 
> doesn't always
> > > > make sense). This is one of the areas we are trying to 
> change, so it
> > > > correctly takes into account the advantages of using packet. 
> > > ...
> > > 
> > > 
> > > This whole conversation appears to be predicated on some 
> > > tacit and false
> > > assumptions.
> > > 
> > > The principal assumption seems to be that the entire 
> capacity of a hop
> > > is taken up with VOICE conversations so that the solution to
> > > oversubscription is to shed some of those VOICE conversations.  
> > > 
> > > If you come to the conversation with a bellhead 
> mentality, then we can
> > > probably read up on Erlangs and reach much the same 
> > > conclusion that the
> > > circuit switch world reached years ago.
> > > 
> > > 
> > > If you have a priority voice conversation and experience 
> > > congestion, it
> > > would seem to me that we would want to bump something 
> other than other
> > > voice conversations:
> > > 	- anything file transfer (incl e-mail enclosures) with 
> > > .ppt in the file
> > > label.  The content:bit-bloat ratio there is terrible to the 
> > > extent that
> > > I'm calling powerpoint a virus these days.
> > > 	- cut back a VTC to voice only.  The psychologists tell 
> > > us that a
> > > talking-head VTC has visual cues that we use for about 
> 5-10 minutes;
> > > after that we might as well turn the video off and just leave the
> > > audio.  The problem here is that we can't know by looking at port
> > > numbers whether someone has turned the camera around and is 
> > > sharing view
> > > of a crime scene
> > > 	- filter out any ftp-based operating system installs 
> > > (they can wait). 
> > > Only picking on this example because I did it this morning.
> > > 	What we have to be careful not to do is filter out 
> > > things that are
> > > higher priority than the priority voice conversation.  LSAs 
> > > (router link
> > > state announcements, necessary to keep the network converged and
> > > functioning) is one example.  
> > > 
> > > 
> > > -- 
> > > b
> > > 
> > > 
> > > _______________________________________________
> > > Ieprep mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ieprep
> > > 
> > 
> > _______________________________________________
> > Ieprep mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ieprep
> -- 
> b
> 
> 
> _______________________________________________
> Ieprep mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ieprep
> 

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep