Re: shim6 @ NANOG (forwarded note from John Payne) (fwd)

[Iljitsch van Beijnum <iljitsch@muada.com>]

Just a few quick points...

On 1-mrt-2006, at 9:10, Igor Gashinsky wrote:

> :: > Right. So there is precedent for storing state for 30000  
> instances of
> :: > "something". Servers are getting a lot faster and memory is  
> getting
> :: > cheaper so adding a modest amount of extra state for longer lived
> :: > associations shouldn't be problematic.

> :: > (Visit a run of the mill content provider and see how many 100  
> byte
> :: > GIFs they send you over HTTP connections that have 700 - 1200  
> byte
> :: > overhead and of course all have high performance extensions  
> turned on
> :: > for extra bandwidth wastage.)

> Wow.. I realize I'm coming a little late to this party, but have  
> you asked
> anybody who works for a large-ish content provider about their views
> on what you are suggesting?

Not in this particular area, so far.

Note that shim6 is still a moving target. One way to optimize things  
for hosting providers would be to do an incomplete shim6 negotiation  
or remove the state on the server side as soon as it's created. As  
long as the client knows all the server's addresses and any failures  
are visible at the client (which would be the case for normal TCP  
traffic) the client can renegotiate the state when there is a failure  
that needs to be repaired. This way, shim6 doesn't have much impact  
on servers.

> Case and point: we all know that http/1.1 + keep-alive is
> more "efficient" from a bw perspective, yet there are some large  
> web shops
> which force all transactions into http/1.0 +no-keep-alive in order  
> to use
> "accept-filter" and therefore save on application state.

That's unfortunate, because reusing sessions makes the web experience  
much faster for people who sit far away from the server.

> sessions are fairly "few" per
> server) are very short-lived http (think about 15 packets in each
> direction including the setup/teardown). Since, shim6 (as designed  
> right
> now) does not initiate from the first packet(s), it might not take  
> effect
> for these short-lived sessions, and therefore will not help in case of
> failure, so in effect, *does not work* at all for fast http  
> transactions

The idea is that if you have a single short lived session, the chance  
that something bad happens during that second the session is around,  
is so small that it's not worth it to negotiate shim6. But if you  
have many short sessions, they add up and at some point shim6 kicks  
in. The current suggestion is to do this after 50 packets between the  
hosts involved, regardless whether this is 16 sessions or 1. But this  
is something that can and should be tuned by operators.

> For example, in the v4 world, the (multi-homed) end-user maybe
> visible via both a *paid* Transit path (say UUNET), and a *free*  
> peering
> link (say Cogent), and I would wager that most content providers would
> choose the free link

This is not what I think of when I say "multihoming". I don't see an  
easy way to do this with shim6 (there may be a non-easy way, though)  
so maybe hosting companies that are big enough to do peering will  
need to continue to do this as in IPv4.

> So,
> whatever methodology we use to do the initial set-up has to account  
> for
> that, and be able to get a connection that is actually starting to do
> something in under 2 seconds,

If anything, 2 seconds is on the long side.

> Just my $0.02

They are appreciated, thanks. (IETF budgets the way they are...)