[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] ALT's strong aggregation often leads to *very* long paths
- To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
- Subject: Re: [RRG] ALT's strong aggregation often leads to *very* long paths
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Thu, 31 Jan 2008 11:17:39 +1300
- Cc: rrg@psg.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LWyPFBFUSda6Fe1ydMiQiF0HMGuJ1TMZxeSTDsz/6mQqh+gPxTooS5wiSLHa5hN2BrjKM0SdZ9h+KwyhBB1MYg7YC6ffZHYoRGl4wtFt7Ca17dXH98K2OjGaez/fGA156DRAHCCm+Vr7yJ/R+yuhPdtxszsH2wpyqAWGq4Fld1I=
- In-reply-to: <20080130130507.5D2548730C@mercury.lcs.mit.edu>
- Organization: University of Auckland
- References: <20080130130507.5D2548730C@mercury.lcs.mit.edu>
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
Regardless of the details, is it a surprise that the path
taken by initial packets while waiting for a mapping have
significantly greater length than the path established
after the mapping arrives? There seems to be an inevitable
design choice between:
1. Discard those packets;
2. Queue them;
3. Send them a long way round.
All these choices are compatible with the datagram model,
so I don't see how any of them can be architecturally
"wrong". From an engineering viewpoint, #3 seems
reasonable (i.e. this minor delay will be added to the
other delays for starting an application-level session).
Brian
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg