Re: comments on draft-park-pppext-mip6-co

James Carlson <[email protected]>
Newsgroups gmane.ietf.pppext
Message-ID <[email protected]>
Bernard Aboba writes:
> > Why is a single round-trip time important?  Are there really links
> > where this round-trip time is significant compared to any network
> > layer traffic that might flow on the link?
> 
> The absolute value of the round-trip time may be significant on links such
> as GPRS or UMTS where RTT can be 800-5000 ms.  Network layer traffic will
> experience the same level of delay, however.

As Vern and others have pointed out repeatedly (and, yes, this is my
paraphrasing, so don't blame him for it; blame me instead): if a
single RTT is a heart-breaker, then you're just not going to be able
to use the resulting link for any reasonable networking-related
purposes.  Shortening the IPV6CP negotiation time doesn't help a whit
unless you really think you're going to bring the link up, send out
one packet, and then slam it back down again.

So, the question still stands: in what scenario is the connection
set-up time an _appreciable_ fraction of the time spent conversing
with network peers, such that eliminating a single RTT will actually
result in some noticeable and worthwhile benefit versus the disruption
that adding (and deploying) yet another option will incur?

> > Is this perhaps papering over implementation flaws, such as an
> > inability to buffer datagrams when the link is down or (maybe)
> > triggering retransmit at opportune times?
> 
> The high RTT times in GPRS/UMTS are in part due to large buffers in the
> GGSN;

Perhaps I don't understand some crucial part of the architecture here,
but shouldn't those buffers be essentially empty (and delay minimized)
at the point where we're still just bringing the link up?

>  today's TCP implementations may cause those buffers to fill,
> resulting in very high RTT values, and somewhat unstable TCP performance.

Sounds like IPV6CP is just about the least of the worries.

-- 
James Carlson, IP Systems Group                <[email protected]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.