Subject: AW: [Diffserv] QoSSIG BOF

From: Hummel Heinrich <[email-masked]>
Date: Tue, 25 Jan 2000 16:55:52 +0100

Nothing is bad with Juha's opinion. Just the opposite:
IMHO we could accomplish such fast transmissions if not only the
transmission of the user data
is fast but if the processing/forwarding of the message for establishing
either an SVC or an LSP is   fairly as fast as
the forwarding of the user data packets. 

Some time ago K.K. Ramakrishan from Bell Research Lab presented his UNITE
concept both in the ATM Forum and IETF.
Accordingly a single ATM-cell would contain a Mikro-SETUP message to
establish an SVC resp. an LSP.
This message could be forwarded based on a - let me say- "pilot-VPI/VCI
resp. pilot- label" residing  in the ATM-payload (not cell header !).
In order to do pilot-switching however the switching tables of each transit
switch/LSR must be properly filled based on a protocol
that "happens"  earlier.  

Accordingly complexity is shifted away. Complexity as such cannot be
ignored, because the topology of a network changes from time to time. 
The protocol for "pilot-label distribution" must take this into account.

With such a protocol the so-called N-square problem would be solved too. If
the current N of the current internet is equal to 70 000
then any "pilot-router" would have to provide N=70,000 pilot-label switching
entries (or may be 3 times 70,000 in case it will  support 3
routes to the same destination router reflecting 3 different QoS classes !
But never N*N many ! )

Heinrich 

> -----Ursprüngliche Nachricht-----
> Von:	Michael Welzl [SMTP:[email-masked]]
> Gesendet am:	Dienstag, 25. Januar 2000 14:45
> An:	'Hummel Heinrich'; 'Juha Heinanen'; 'Yoram Bernet'
> Cc:	'Joakim Bergkvist'; 'RSVP'; 'diffserv'; [email-masked];
> [email-masked]
> Betreff:	RE: [Diffserv] QoSSIG BOF
> 
> I don't understand that.
> What's so bad about Juha's opinion that we should avoid making a
> complex protocol like RSVP even more complex?
> 
> 
> > 	Juha,
> > 
> > 	Great. Let us develop a new protocol that enables any webpage
> > anywhere in the internet being downloadeded within a fraction
> > 	of a second. I would enjoy to do so.
> > 
> > 	Heinrich Hummel
> > 	Siemens Munich
> > 	[email-masked]
> > 	  
> > > Yoram Bernet writes:
> > > 
> > >  > What I opposed was scrapping RSVP. My suggestion was 
> > that the forum
> > >  > should take RSVP as its opening position and then work out how to
> > > modify it
> > >  > to suit the requirements.
> > > 
> > > it doesn't make sense to add even more options to an already complex
> > > protocol.  whatever is produced, must be very simple to 
> > read, understand,
> > > implement and use.
> > > 
> > > -- juha
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Tue, 25 Jan 2000 18:03:21 +0100

> the forwarding of the user data packets. 

Handling signaling messages in the fast path - this sounds very much 
like our Boomerang proposal, except that there we wrapp the 
reservation message into an PING. In our Linux based router prototype, 
processing a Boomerang message takes only 20% more time than 
forwarding a data packet of same size. For our drafts and related papers 
look at		http://boomerang.ttt.bme.hu/
 
> > > > protocol.  whatever is produced, must be very simple to 

--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: [email-masked]
--------------------------------------------------