Re: [Tsvwg] TCP and UDP MIB issues

[Gorry Fairhurst <[e-mail]>]

I agree these new features could be applicable to UDP-Lite, as well as 
UDP. The situation is only different in that we are currently seeking to 
standardise the first MIB for UDP-Lite (preferably simple and therefore 
more likely to be implemented), whereas the UDP MIB has already been 
widely deployed.

What I do not yet know is whether the best approach is to choose one of 
these methods (either 2 or 3) for inclusion as an optional part of the 
proposed UDP-Lite MIB, or whether to await a fix (MIB extension) that 
could apply equally to UDP-Lite and UDP (giving more consistency). 
Unless people really need these features urgently for UDP-Lite, I'd 
suggest a consistent approach is better.

Have you thought about bringing the I-D to the TSV WG for discussion at 
the next IETF, it is often helpful to get feedback on the best way 
forward from the working groups that maintain the protocols that a MIB 
relates to.

Gorry

Anders Persson wrote:

> Gorry,
> 
> The same general issue does seem to appear within the UDP-Lite MIB, 
> which is how to deal with multiple processes using the same UDP-Lite 
> endpoint. For example, on a system using sockets, you can have one 
> socket being shared between multiple processes if the creator of the 
> socket uses fork() to create child processes. However, with the current 
> MIB it is only possible to associate one processes with an endpoint.
> 
> There are at least four ways this could be addressed:
>    (1) Use udpliteEndpointInstance to create multiple entries. 
> Unfortunately, this approach
>         makes it look like multiple independent endpoints, which might 
> be a bit deceiving
>    (2) Make udpliteEndpointProcess part of the INDEX
>    (3) Create a new Identifier object (like tcpEStatsConnectIdEntry), 
> which could then be
>         referenced by other tables. For example, we could then have 
> udpliteProcessTable
>    (4) Create udpliteProcessTable that mirrors the INDEX of 
> udpliteEndpointTable, but adds
>         udpliteEndpointProcess to the INDEX as well :-(
> 
> My personal choice would be (3), as it allows the MIB to be extended in 
> the future.
> 
> Cheers,
> Anders
> 
> Gorry Fairhurst wrote:
> 
>>
>> Generally, the proposed UDP-Lite MIB follows that for UDP (supporting 
>> both multicast and unicast). It does differ in the udpliteEndpointTable:
>>
>> http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt
>>
>> If there are implications on the UDP-Lite MIB, we'd be pleased to try 
>> to understand what these are, and any ideas of what we should do.
>>
>> Best wishes,
>>
>> Gorry
>>
> 
> 
>