<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:10pt"><P>OK, Bob. If you say we disagree, you know best :-)</P>
<P> </P>
<P>Dirceu</P>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Bob Briscoe <rbriscoe@jungle.bt.co.uk><BR>To: Dirceu Cavendish <dirceu_cavendish@yahoo.com><BR>Cc: iccrg@cs.ucl.ac.uk<BR>Sent: Monday, April 7, 2008 4:21:28 PM<BR>Subject: Re: [Iccrg] Heresy following "TCP: Train-wreck"<BR><BR>Dirceu,<BR><BR>If you say we're agreeing, then OK.<BR><BR>But I read a lot of tell-tale signs in your various postings that <BR>imply to me you are still thinking the way I believe has been a <BR>mistake in the past.<BR><BR>For instance, it's not at all hopeless if all sessions don't pass <BR>through a core router - they still have to pass through the point <BR>where the user's trust domain attaches to the rest of the Internet. <BR>That's always the case (otherwise the user isn't attached to the <BR>Internet). So there is no problem* seeing all the user's flows in one <BR>place (or a small number of
places if multi-homing).<BR><BR>However, let's leave this one at that for now.<BR><BR><BR>Bob<BR><BR>* The outstanding problem is that you can't see congestion ahead in <BR>the rest of the Internet from the attachment point (our re-feedback <BR>solution is one way to ensure trustworthy information about remote <BR>congestion is visble in packets crossing this attachment point).<BR><BR><BR><BR>At 23:55 07/04/2008, Dirceu Cavendish wrote:<BR>>Let me state one thing clearly, first of all. I am NOT disagreeing <BR>>that flow rate equality as a fairness criterion has its problems. <BR>>So, you do not have to be defensive, as your last paragraph below.<BR>><BR>>Second, about routing, I think you were the one who did not captured <BR>>what I wanted to say - communication is always a two way process, so <BR>>I take the blame as well. I understand that multiple sessions do not <BR>>require diverse routes in order to "confuse" routers, so
as to <BR>>defeat some fairness scheme. However, one may imagine that, the same <BR>>way the router of application "attachment" is able to correlate <BR>>multiple session into a single application - as one of your papers <BR>>mention, a core router might be able to do it, provided that all <BR>>sessions follow the same path. When that is not the case, then the <BR>>situation is REALLY hopeless...That is what I meant.<BR>><BR>>I believe we are in violent agreement, overall :-)...<BR><BR>____________________________________________________________________________<BR>Bob Briscoe, <<A href="mailto:bob.briscoe@bt.com" ymailto="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</A>> Networks Research Centre, BT Research<BR>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 <BR><BR><BR></DIV><BR></DIV></div><br>
<hr size=1>You rock. That's why Blockbuster's offering you <a href="http://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com">one month of Blockbuster Total Access</a>, No Cost.</body></html>