Subject: RE: QoS and adaptive end protocols

From: Mudassir Tufail <[email-masked]>
Date: Wed, 21 Jun 2000 10:18:25 -0700

The motivation of such deployments (IP over ABR) is better fairness with
ABR than UBR in general. It is not evident to witness any improvement in
performance with ABR except if we are able to tune ABR loop with TCP control
loop and to provide large buffers at the routers which interface ATM
network.

Mudassir
CALY Networks              
295 Santa Anna Court       
Sunnyvale, CA 94086        

> -----Original Message-----
> From: Dan Grossman [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 7:51 AM
> To: Manfredi, Albert E
> Cc: 'demir'; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: QoS and adaptive end protocols 
> 
> [.....]

> I have been told that there are large deployments of IP over 
> ATM with ABR, and that they have excellent goodput (sorry, 
> that's about as much as I can talk about).  Unfortunately, I 
> don't expect to see any published measurement results from 
> these networks.
> 
> My own hypothesis:  
> Perhaps the best way to think of ABR and its interactions 
> with TCP is that the ATM network provides a  near-constant 
> delay, low loss subnet that deals with competing flows by 
> varying the available cell rate.  TCP is looking, ideally, 
> for a fixed bandwidth, near-constant delay Internet that 
> deals with congestion by varying the packet loss rate.  Edge 
> routers can fairly easily adapt the characteristic of the ABR 
> subnet to match the behavior desired by TCP.  One could argue 
> that by pushing congestion to the edge devices (and thus 
> keeping goodput high in the ATM core), system goodput 
> increases.  Also, since ABR **with ER**  is very fair,  
> pushing packet dropping to the one queue in the edge device 
> is likely to be more fair than the net effect of active queue 
> management in every device in the core.
> 
> Dan  
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 21 Jun 2000 18:06:37 -0400

> > I would ask the question differently to understand why service
> > differentiation might be desirable. I would ask, if a 
> network offers good
> > service for adaptive Layer 4 protocols, does it need to do 
> more? Are there
> > applications running over that same network which don't 
> coexist well with
> > adaptive Layer 4 protocols? And I think the answer is 
> definitely yes; at
> > least yes for now.

> Yes. I agree. However, I am questioning if adaptation is 
> necessary/would
> help. The QoS-network can have additional mechanisms to 
> protect adaptive
> flows.

So, you mean why not chuck TCP and just allow the network to do the adapting
at lower layers? But there are cases where the end systems need to introduce
feedback to adjust to their own internal limits (NICs, OSs, internal buses,
DMA, whatever). FTP is a good example. The network can't know those internal
limits, right? So both solutions are needed.

> > A parallel effort might be to create ever more adaptive 
> protocols, even for
> > voice and video. But again, people will still demand 
> quality if they are
> > paying for it. So this is not always the answer.

> isn't it network's responsibility to provide quality if users 
> are paying
> for it?

Yes. What I meant above was that even if you can use RTP's control protocol
(RCP) to cause an encoder to adjust the quality based on network
performance, that _might_ not be an acceptable solution, so some sort of
network QoS guarantee is desirable. For example, if you're using the
Internet to watch a porn flick on demand, perhaps high definition, and
you're paying for it, most people would be mighty annoyed if network
congerstion caused your flick to suddenly arrive in 15 fps H.320
teleconference quality.

Bert
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Jun 2000 16:12:22 -0700

At 03:25 PM 6/21/00 -0400, Manfredi, Albert E wrote:
>One round-trip time would be the minimum for ABR, and in large ATM
>backbones, how would this differ from TCP's loop?

well, judging from trace-routes I do from here, quite a bit. TCP's loop 
includes host delay, and ATM's loop is always within one provider - but to 
go anywhere interesting, I have to go through my network, my ISP, their 
ISP, their their network. That's a minimum.

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Jun 2000 16:14:39 -0700

At 06:06 PM 6/21/00 -0400, Manfredi, Albert E wrote:
>you mean why not chuck TCP and just allow the network to do the adapting
>at lower layers?

retransmission...

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 22 Jun 2000 01:44:17 +0100

that's what wireless folks do in acknowledge mode (this allows
for decent transmission of TCP on the wireless medium by lowering
the size of the minimum retransmission unit and by improving BER
perceived by TCP...). Of course only on one link  (or two)
of the end to end path.

> ----------
> From: 	Fred Baker[SMTP:[email-masked]]
> Sent: 	22 June 2000 00:14
> To: 	Manfredi, Albert E
> Subject: 	RE: QoS and adaptive end protocols
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Jun 2000 17:51:50 -0700

At 01:44 AM 6/22/00 +0100, Casati, Alessio (Alessio) wrote:
>that's what wireless folks do in acknowledge mode...Of course only on one 
>link  (or two)
>of the end to end path.

yup. And that's dandy for those links. It really helps. That said, it 
doesn't help end to end, and you can't chuck the protocol that does end to 
end retransmission if you don't have another e2e retransmission scheme in mind.

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 22 Jun 2000 09:43:45 +0100

FB wrote:

> doesn't help end to end, 
It does help end to end in that it makes the loss due to error
smaller (which is known to be beneficial end to end for TCP).

alessio

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Jun 2000 09:41:01 -0700

>smaller (which is known to be beneficial end to end for TCP).

Argh. Last time I'm sending this note.

Yes, it improves the probability of end to end delivery of the IP datagram, 
by setting the probability of non-loss term for that link to 1. You now 
only have to worry about the probability of loss on each of the other 
links, but not that one.

Third try, hope this is more clear. In the X.25 world and the SNA world, 
there was a belief that doing ARQ on each link individually would result in 
each link having perfect reliability, and as a result the end to end path 
would be reliable. TP2, you will recall, was engineered because that turned 
out to not be true. End to end reliability is not about the sum of the 
links, it is about the end to end path, and while improving each link helps 
measurably, to have end to end reliability, you have to have a protocol 
which goes end to end and ensures reliability.

It doesn't have to be TCP, but it does have to be there.

Someone asked whether, if the network was a QoS network (whatever that is) 
we still needed TCP. Part of that question was whether TCP would still have 
to adapt, and part was whether it was needed at all. My statement was that 
you need a protocol to ensure end to end reliability.

Improving the reliability of one of the links en route helps, and I'm glad 
that the CDMA folks are doing that. Thanks for playing. That link is not 
end to end, and doesn't fix the end to end problem.