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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 14:06:01 -0500

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

---

From: Rex Buddenberg <[email-masked]>
Date: 01 Dec 2003 11:45:15 -0800

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.  

-- 
b