Re: [shara] [BEHAVE] Pref64 nature and referral support.

[<[e-mail]>]

Inline,

>-----Original Message-----
>From: ext Rémi Després [mailto:[e-mail]]
>Sent: 24 January, 2009 12:07
>To: Brian E Carpenter
>Cc: Dan Wing; 'Behave WG'; Savolainen Teemu (Nokia-D-MSW/Tampere)
>Subject: Re: [BEHAVE] Pref64 nature and referral support.
>
>>> As chair, I would certainly like to see documents that detail such
>>> proposals.  A discussion of the trade-offs and benefits would be
>>> valuable.
>To my knowledge, and for example, Teemu Savolainen ran a test
>in August 2008. It showed that a Google map use involved 4
>server addresses in parallel. With port dependent mapping on
>port 80, the number of needed client ports would have been
>divided by 4 .

Correct.

To be more exact, one test showed burst of 8 SYNs:
- TCP SYN to 74.125.77.136:80 (local port 1380) => requires new local port reservation 1
- TCP SYN to 74.125.77.136:80 (local port 1381) => requires new local port reservation 2
- TCP SYN to 74.125.77.93:80 (local port 1382) => could have shared existing local port '1'
- TCP SYN to 74.125.77.93:80 (local port 1383) => could have shared existing local port '2'
- TCP SYN to 74.125.77.91:80 (local port 1384) => could have shared existing local port '1'
- TCP SYN to 74.125.77.91:80 (local port 1385) => could have shared existing local port '2'
- TCP SYN to 74.125.77.190:80 (local port 1386) => could have shared existing local port '1'
- TCP SYN to 74.125.77.190:80 (local port 1387) => could have shared existing local port '2'

I.e. 8 different TCP sessions could have been multiplexed into 2 local ports.

And another test showed burst of 16 SYNs:
- TCP SYN to 74.125.77.93:80 (local port 1906) => requires new local port reservation 1
- TCP SYN to 74.125.77.136:80 (local port 1907) => could have shared existing local port '1'
- TCP SYN to 74.125.77.91:80 (local port 1908) => could have shared existing local port '1'
- TCP SYN to 74.125.77.91:80 (local port 1909) => requires new local port reservation 2
- TCP SYN to 74.125.77.190:80 (local port 1910) => could have shared existing local port '1'
- TCP SYN to 74.125.77.190:80 (local port 1911) => could have shared existing local port '2'
- TCP SYN to 74.125.77.190:80 (local port 1912) => requires new local port reservation 3
- TCP SYN to 74.125.77.136:80 (local port 1913) => could have shared existing local port '2'
- TCP SYN to 74.125.77.136:80 (local port 1914) => could have shared existing local port '3'
- TCP SYN to 74.125.77.93:80 (local port 1915) => could have shared existing local port '2'
- TCP SYN to 74.125.77.91:80 (local port 1916) => could have shared existing local port '3'
- TCP SYN to 74.125.77.93:80 (local port 1917) => could have shared existing local port '3'
- TCP SYN to 74.125.77.93:80 (local port 1918) => requires new local port reservation 4
- TCP SYN to 74.125.77.136:80 (local port 1919) => could have shared existing local port '4'
- TCP SYN to 74.125.77.91:80 (local port 1920) => could have shared existing local port '4'
- TCP SYN to 74.125.77.190:80 (local port 1921) > could have shared existing local port '4'

For me it looked like there could have been possibility for 75% local port savings in these two scenarios.

Of course if the destination server is having just one IP address, these kinds of savings would not be possible for such applications utilizing multiple parallel transport sessions. Maybe these kinds of applications should be hosted by servers with multiple IP addresses (even if all configured for same interface)?

What comes to hosts possibly having port restricted IP address allocated to themselves, it would seem they should utilize address dependent mapping (when applications are utilizing implicit source port bindings) to save ports in these kinds of use-cases (also in the case where the host implements internal NAT (for serving non-port-restricted IPv4 address compatible applications)).

Best regards,

        Teemu